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).
If an exception is thrown, a dialog is shown. This isn’t very user friendly, but the goal is to call attention to the problem, as I wouldn’t expect any exceptions to be thrown by this method, but I have seen multiple “optimistic locking failure” exceptions despite single-app / single-thread access to the persistent store.
This is only done for code where running it twice would actually cause a problem.
Dispatch_once is favored over a static boolean only because it seems to carry slightly more semantic information.
Since we save the history during applicationWillTerminate: there is (in theory) no reason to periodically save the history, but in case of a crash or similar, we would not get to applicationWillTerminate:.
Previously this was stored in NSUserDefaults. The problem with that approach is that if large items were stored in the history, it would cause slowdowns, presumably by periodic writing the entire user defaults to disk.
Remove logic from the setter methods and limit their use. This is in preparation for making the classes NSManagedObject subclasses where we prefer to use the generated accessor methods.
We shouldn’t use Apple’s prefix for our own constants. The actual value of the constant hasn’t been renamed yet as this requires “migration” (renaming the key in user defaults).
