Accessibility rotors allow VoiceOver user to navigate content quickly
by making possible navigation through select elements only.
In this case, we enable VoiceOver users to navigate efficiently
through symbols.
The first way to invoke a rotor is a "global" one (does not take into
account current position in text) and is invoked with VO-U. After
pressing arrow left/right sufficient times to reach "Symbols", one is
presented with a list analogical to the "Jump to symbols" TextMate
feature invokable by Shift-Cmd-T. Arrow up and down then enable
navigating through items, Return selects the result (and jumps to it),
Esc cancels the interface without moving the cursor. Also filtering
the list works by simply typing characters (implemented as
case-insensitive substring search - consistent e.g. with Safari's
"Headings" rotor).
The second way to use a rotor is a "local" one (navigates w.r.t. the
current position in text) and is typically done through Trackpad
Commander (turned on by VO + two finger "screw" gesture to the right
on the Trackpad). Then one uses two-finger "screw" gesture (like
(un)screwing the bottle lid from/to the bottle with thumb and index
finger) to select "Symbols". When this is finally selected (the
selection is persistent), the user can then use flick with one finger
up or down gestures to move to the previous/next occurrence respectively.
I made a choice at one spot - I report the "symbol location - end of
hardline" as the range of the symbol (that is e.g. what VoiceOver
reads when navigating the elements). This seemed to work best for the
user at least in the Objective-C code.
The APIs are 10.13+ only, so appropriate avaiability declarations are
put in place to not cause warnings from the compiler. I was not sure
whether some declaration like that is needed also for the
OakTextView's informal category's conformance to the
`NSAccessibilityCustomRotorItemSearchDelegate` protocol - the protocol
is 10.13+ only too, but the compiler does not warn about conforming to
it. Perhaps the Objective-C runtime is smart enough to take into
account that the `NSAccessibilityCustomRotorItemSearchDelegate` symbol
is (hopefully) weakly-linked and adds conformance to it (I assume
using the `class_addProtocol` function) only when it is non-nil. I
have however not tested whether the compiled app actually degrades
gracefully (without crashing) on macOS 10.12 and earlier, though (for
starters, I seem not to have access to a macOS Sierra image to create
a VM).
The button created on 10.12 or 10.13 has a “Button” label next to it when used in table views (as used in the Find in Project results and Commit sheet).
See https://lists.macromates.com/textmate/2019-January/040883.html.
The issue is caused by commit f850dbdbc7, which added support for font style changes. It did so by applying a single font across the entire string. But, in some cases not all characters (e.g., Chinese or Japanese characters) may be available for that font so these characters would not be rendered correctly while editing.
This fixes the problem where a folder search has been done and the dialog is later re-opened for another project (which will then take ownership) and then selecting one of the old search results: The “select match” is now sent to the project that was active, when the search was performed.
It appears to be ignored on 10.14 but earlier versions of macOS rendered the elements with a shadow, which is probably not a good fit for our current design.
An alternative to accessing the cell directly is using NSAccessibilityUnignoredDescendant to obtain the object, but while it seems to abstract away whether or not it is the control or its cell which participates in accessibility, we forego the type checker.
Semantically this seems slightly more appropriate, and giving a range allows us to pass the strings length as the length of the range, instead of assuming that the string has a first character for which we can get attributes, although for an empty string, passing in a zero-length range *does* throw an exception, so we must only call this when we know the string is non-empty.
macOS 10.10 SDK introduced new protocol-based accessibility APIs. The
old accessibility APIs are now deprecated. These APIs require a
minimum deployment target of 10.10, which is fulfilled since TextMate
2.0 rc 12.
Main changes connected with this new API is that it is statically
typed, so it is no longer necessary to convert parameters from (and
results to) NSValue objects.
Still some of the weakly-typed original APIs are not deprecated and
have no alternative in the new API, notably e.g. the
accessibilityArray* methods, so they are kept.
At least on macOS 10.14 the auxiliary titlebar view is placed so that the bottom line of the view overlaps with the divider that separates the titlebar from the window content.
While the tab view background color is using alpha, the divider was still visible, but it didn’t look that good when using the light appearance.
The problem with having the check in updateToLayout: is that the background view that extends to right window edge is not part of the layout, so while the width of this view may change when resizing the window, it would not result in a different layout.
This doesn’t do any caching of style lookups so performance is worse than theme_t and it also lacks an API to control the initial base font.
For now, the intention is to use this for system dialogs, such as the Find dialog, but long-term it should also be used by OakTextView, at which point, caching and base font support should be added.
When requesting clipboard content using stringForType: then NSPasteboard will automatically join all strings using a newline character, so copied results will still paste as a “list” but applications that are aware of multiple pasteboard items could potentially do something different.
This is the “modern” API that supports multiple items on the clipboard and gives us a badge to show how many items are being dragged.
Though the default drag image does not resemble Finder nor does it seem to support flocking out of the box (where multiple items are collapsed into a single proxy image).
We ship with the “Update Gutter” command enabled by default which is causing a small delay when opening documents because bundle items are currently blocking the main thread.
This commit (together with the previous one) makes it so that we only call it when we have an assumption that it will actually update the gutter.
This is because we may sometimes want to enable implicit animations when updating this property, by making it read-only we limit places from where it can be updated, to make it easier to audit the code.
Currently no-one outside the class actually uses the property, so we could (and may) make it private.
Based on crash reports, some of these functions do fail in practice, mainly due to “too many open file descriptors”, in which case we should let the io::spawn function fail, rather than crash the program.
The io::spawn function is used (amongst others) to update SCM status, so a failure is not always worth notifying the user about (beyond logging an error).
Not sure why the width of this control has been limited as the content of the pop-up is somewhat fixed (unlike e.g. the grammar or symbol pop-ups, which can contain extremely wide entries).
