Previously when opening a submenu from a menu, the main menu disappears because a issue with the poolMenuWindow.
This PR fixes this bug.
It also handle more properly the case when an user is making several right clicks on a responder (origin problem with the ghost menu).
Fixed#1887
Previously, the auto-enabling logic for CPMenu would not check to see if a menu item had enabled bindings, and would ignore the state determined by those bindings.
Now, if a menu is auto-enabling and an item has an enabled binding, the binding is used to set the enabled state of the item.
Without this fix, if a menu item was disabled it could only be automatically re-enabled if the menu item had a `validateMenuItem:` or `validateUserInterfaceItem:` enabled target.
This meant that for example if the Edit > Select All menu item was validated when the first responder was something like a collection view, it'd become disabled. If then the first responder was changed to a text field and revalidation occurred, the menu item would not become enabled and Select All would not be possible in the text field neither through the Edit menu nor the Cmd-A/Ctrl-A keyboard equivalent.
This fix ensures that menu item validation does not only take negative action (disabling enabled items which should be disabled), but also positive action (enabling disabled items which should be enabled), even when there's no `validateMenuItem:` or `validateUserInterfaceItem:`.
This replaces the previous solution with one proposed by @BlairDuncan. It uses the _highlightItemAtIndex: method to maintain the highlight state, rather than setting the _highlightIndex variable directly.
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
When a menu is active, menu selection should change as characters are typed.
This can be seen in the manual CPMenuTest.
It used to work in the past but with all of the changes in the last few months to the compiler I
was not able to track down the exact commit that broke it. The code responsible for
clearing the _keybuffer after a brief delay in typing, was not being called,
resulting in a build up of characters.
This commit moves the check for delay to the interpretKeyEvent and takes care of
clearing the _keybuffer itself and removes that responsibility from the selection method.
Previously it wasn't possible to theme the main menu of the app. With this fix the user can either theme the main menu with the theming system or with the method +setMenuBarAttributes from CPMenu.
Previously, if a pull down menu was brought down from a pop up button in pull down mode, clicking the button again would close and reopen the menu.
With this fix the behaviour becomes like in Cocoa, and clicking the button a second time simply closes the menu.
This was caused by the menu opening up below the button. When the menu manager examined this event it saw a click outside of the menu and immediately closed the just opened menu. Then it put the opening event back on the event queue, causing the pop up button to try to open its menu again.
The fix ignores the opening event for purposes of detecting clicks which should close the menu.
Refs #1833.
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.
Previously, clicking outside a menu on a control would not close the menu. Also clicking on the menu header again would open a second menu.
This error was caused by the control receiving the click and starting its own tracking, depriving the menu of the mouse up event it was awaiting.
The behaviour to wait for the mouse up was wrong to begin with. Menus should close on mouse down.
This fix closes the menu on left mouse down anywhere but the menu, while still allowing the click to pass through to any control underneath the cursor.
Fixes#1833.
Previously, all window subclasses were constrained to the usable screen content. Unfortunately that included the menu bar window, which ended up appearing below itself!
This commit introduces an ivar that indicates whether instances of the window subclass should be constrained or not.
Fixed: mouseEntered and mouseExited mixed up for custom views in menu
Previously, when clicking and dragging inside a menu, mouseEntered and mouseExited were sent to the wrong views.
This commit correctly sends mouseExited to the previous hovered view, then mouseEntered to the new hovered view.
Previously, if CPApplication -targetForAction:to:from: returned nil, no check was done to see if that failed because there was no action or no valid target. If the item had no item, no target, and to action binding, it would be left enabled, which was incorrect.
This commit fixes the validation to disable the item if targetForAction:to:from: returns nil and the item has an action or target.
- Popovers are implemented as child windows.
- Renamed _CPAttachedWindow/_CPAttachedWindowView to _CPPopoverWindow/_CPPopoverWindowView, since that is its only use.
- The default for CPView -acceptsFirstMouse is now NO, per Cocoa. Subclasses override this as necessary.
- _CPWindowView -hitTest returns self it the mouse is within a resize region, which may be outside the window's frame.
- Fixed an off by one bug in CPDomWindowLayer -insertWindow:atIndex:, where inserting a visible window behind a window it is already behind would cause it to move up one from its intended position.
- Updated the ChildWindows and CPPopover test apps.
Didier KorthoudtandGitHub
Martin CarlbergandGitHub
daniel
daboe01
Antoine Mercadal
Alexandre Wilhelm
Aparajita Fishman
Alexander Ljungberg
Andrew Hankinson
Blair Duncan
aparajita
Stefan Wallström
Aparajita Fishman