This change was prompted by the appearance of the `tabSizePopUp` button in the status bar. After dismissing the menu, the title would be disabled.
To ensure we do not have similar issues elsewhere, let's prefer the use of `NULL` to `nop:` when assigning the action for menu items unless we are sure that the menu item should always be disabled (e.g., the item is used as a label).
- Path to application is shown in the menu item’s tool tip.
- When menu is shown for multiple file types with different default applications, we show the default applications first.
- Use the potentially localized bundle name rather than file system display name.
- Use bundle identifier to group applications rather than display name: Grouping is done to decide if version number should be shown for the item.
I mainly dislike the trailing zeroes because CGFloat used to be a float but 1.0 is a double (1.0f would be a float). So better to under-specify and let the compiler figure out the proper type.
The text view itself will still dim the selection, but document tabs, status, and tool bars no longer change colors.
This seems consistent with how Apple’s controls act and is necessary for the status bar since it draws a transparent gradient over the window background, so only its borders got the dimmed look.
This function makes it easy to set accessibility "labels" for UI elements.
It is flexible - takes care of NSView vs. NSControl case, labels can be
specified directly as a string or as a user interface element.
The standard doesn’t care which side the keyword is placed on, but placing it on the right makes it easier to read types.
E.g. reading “int const* const” from right to left we get “const pointer to const integer”.
Previously we only updated the system pasteboard if it was different, but some users copy rich text from one application, paste it in TextMate and then copy it (in TextMate) with the expectation that the rich styles are stripped.
Since it is the cell that is providing the accessibility attributes the simplest way I could think of to have it ignored was to remove NSImageView’s support for the NSAccessibilityChildrenAttribute.
I tried using accessibilitySetOverrideValue:forAttribute: but it did not work for me, so a subclass was required.
While code reuse is an added benefit, the main motivation was to fix the appearance of the action popup button in the Find window. The first (placeholder) item in the Find window's action button was assigned a nop action so that when the button was clicked and it's menu validated, the "action" image would always appear as disabled.
An example where this is desired is when doing a folder search for “foo”, then going to first match and using ⌘E to copy the match to the find pasteboard. This is effectively a no-op except for dropping the auxiliary options that contain other documents with matches (which is what causes ⌘G to advance to next document).
There are situations where we create an OakFileIconImage that won’t be drawn, for example when using it with an NSMenuItem. In that case, we previously paid a somewhat noticeable price in the initializer doing work that was not required.
Instead we date stamp each entry and do a sorted fetch (with a limit of one) to find next/previous entry (when required).
The reason for moving away from an ordered collection is twofold, the main reason is that NSArrayController does not support ordered collections, so we lose one of the advantages of switching to CoreData. The secondary reason is that using an ordered collection requires that we use an index for “current item” (or maybe liberal use of indexOfObject:) and it’s problematic to ensure that the index is kept 100% in sync with the entries in the collection (especially with bindings and delayed actions).
