Previously, certain situations could easily lead to an infinite loop in - CPView nextValidKeyView. For instance, opening a sheet view with no responder returning YES for canBecomeKeyView would freeze Cappuccino.
This was caused by the cycle detection in nextValidKeyView not being able to pick up on cycles where the nextKeyView of the original receiver did not participate. Since content views often have a next key view inside of them, and the views inside rarely have a next key view back "up" to the content view, the content view would never be seen again even if there was a cycle.
This fix detects cycles at any level by remembering all previous visited responders.
Without this fix, CGRectFromString would call CGSizeFromString with a value like "{1, 2}}" (not the extra trailing "}"). Although CGSizeFromString didn't complain, it wasn't correct either.
Previously when a menu item was instantiated outside of the context of the menu itself, its highlight state was maintained even after it was removed from the menu. If the menu was dismissed with the item highlighted, and then the item was used in another menu (e.g., re-added to a context menu for a table row) it would appear highlighted, even though the menu highlight index was not set.
This commit ensures that when removing items from a menu that the highlight state of the underlying view is set to NO as well.
Tests for this behaviour are included as well.
Fixes#1899
Previously, Cappuccino was using preprocessor macros internally for the CGPoint/Size/Rect/Inset/Affine functions, as well as for CPRange. These macros had the same name as the corresponding function, but began with _. The functions were actually defined using the macros.
The motivation behind using macros was to increase performance by reducing function calls. However, there were a number of problems with this approach:
- There was an artificial dichotomy between _CG macros and the corresponding CG functions. We never completely replaced CG function calls with _CG macros. In fact, they were often mixed up in the same file. There was an extra burden on the programmer to remember to use the macro instead of the function.
- If a method call was passed as an argument to a macro, performance could actually be significantly *worse* than a function call. For example, _CGGetRectMakeCopy([view frame]) would expand to `{ origin:{ x:[view frame].origin.x, y:[view frame].origin.y }, size:{ width:[view frame].size.width, height:[view frame].size.height } }`. So instead of a single objj_msgSend and a single simple function call, we ended up with 4 objj_msgSend calls, which are way more expensive than simple function calls.
- Because of this expansion problem, to use macros efficiently required us to remember to use variables for all macro parameters. This didn't happen, and shouldn't have to happen.
- Finally, with modern Javascript engines, function call overhead is so small that it really isn't worth using the macros.
This commit eliminates the _CGGeometry, CGAffineTransformation and CPRange macros and replaces them with function calls.
BREAKING CHANGE:
The macros are no longer available. They could only be used with compiled code, but if there is any user code that used them, they will have to be replaced with the corresponding functions.
- Get the scroller orientation from the xib.
- Fix the nonsensical calculation of _isVertical when given bounds.
- Since orientation comes from the xib, had to re-nib2cib everything to be safe.
This fix addresses the following problems:
- fixes a bug with add: where it would try to add the sender object, not the represented object
- changes insert: to insert a new represented object after the currently selected object. If no object is currently selected it behaves like add: and adds a new object to the end.
This patch includes tests.
- It turns out Cocoa DOES recalculate the loop when calling recalculateKeyViewLoop. It does not wait until selectNext/PreviousKeyView is called.
- Cocoa calculates the key view loop for nibs that do not have one, but does not call recalculateKeyViewLoop.
- If there is no first responder and no initial first responder when a window first becomes key, use the first valid key view, not the first geometric key view.
- Made allViews function a method, not sure why it was a function.
- Unit tests now pass.
Before this fix, CPApp tried to add nil to its internal list of windows, even that nil should not be added to a CPArray. Second, that nil was actually returned by [CPApp windows] rather than an expected list of only CPWindow instances.
This fix makes [CPApp windows] return only actual windows, replaces the internal _windows[0] placeholder with CPNull, and ensures this CPNull is never actually exposed outside of the class.
Alexander Ljungberg
Andrew Hankinson
Aparajita Fishman
Aparajita Fishman
Antoine Mercadal
Martin Carlberg
Johan Stille
Ilya Kulakov