AppKit read only CPBundleName for the name that users see, so an application's display name was ignored. It now follows Cocoa, which shows CFBundleDisplayName and falls back to CFBundleName.
* CPApplication.j: Add _applicationName, which returns CPBundleDisplayName or, without one, CPBundleName, and use it as the About panel title.
* CPMenu/_CPMenuBarWindow.j: Use the display name in the browser tab title.
* Tests/Manual/TextEditor/Info.plist: Rename the display name key from CFBundleDisplayName to CPBundleDisplayName.
* Tests/Manual/TextEditor/WORKLIST.md: Remove the entry for this gap, and record the About panel as tested.
Several functions and methods referenced identifiers that were never declared or defined.
* CGColor: Compare color spaces by identity in CGColorEqualToColor, replacing a call to the undefined CGColorSpaceEqualToColorSpace whose test was inverted.
* CGContextCanvas: Declare abs_cos and abs_sin in scale_rotate and rotate_scale.
* CGContextText: Call CGPointMakeZero in CGContextGetTextPosition instead of the removed _CGPointMakeZero.
* CPColor: Compare pattern orientation with CPColorPatternIsVertical instead of BlendKit's PatternIsVertical.
* CPMenu: Declare _CPMenuBarImage with the file's other menu bar variables.
* CPScrollView: Test horizontalScrollerClass and verticalScrollerClass in +frameSizeForContentSize:horizontalScrollerClass:verticalScrollerClass:borderType:controlSize:scrollerStyle: instead of the undefined hFlag and vFlag.
- 8 PLATFORM blocks resolved across four files: runtime CPDOMAvailable
guards (3 wrapped, 2 early returns, 3 if/else preserving existing
CommonJS branches)
- CPMenu: @global _CPDOMEventStop declared; its definition resides in
the DOM-only CPPlatformWindow+DOM category
- zero preprocessor directives remain in these files
- work-in-progress towards complete removal of CPP directives
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.
David Richardson
daboe01
Alfred Wärnsäter
Didier Korthoudt
Martin Carlberg
daniel
Antoine Mercadal
Alexandre Wilhelm
Mathieu Monney
Aparajita Fishman
Alexander Ljungberg
Andrew Hankinson
Blair Duncan