Since this is internal API it should not be necessary to sanitize the range, but based on textmate/bugs#34 it is causing a lot of crashes on macOS 10.15.
The issue is that the types requested may be ‘NSStringPboardType’ but that symbol is deprecated (starting with 10.14), yet the replacement (‘NSPasteboardTypeString’) is not string-equivalent, therefore our simple string comparison would fail.
This effectively broke services starting with 1ef78b3af7 (where we adopted the new symbols).
Implementation of validRequestorForSendType:returnType: does not appear to be a problem, as that method is called with both ‘NSStringPboardType’ and ‘NSPasteboardTypeString’.
Also switched to using NSPasteboard’s writeObjects: so we don’t have to explicitly deal with the type of the data we write to the pasteboard (presumably NSString will declare it using both the old and new type).
The Find dialog was already using number formatters, but the tool tips shown in the text view (when doing searches or replacements without going through the find dialog) were not.
This makes a difference when the count is > 999, as it will then format the number with thousand separators.
This was done using search and replace. Presumably it should be done in Xcode so that it can adjust the xib for the new deployment target, otherwise what is the point of storing deployment version in the xib and provide it as a command line argument to the xib compiler as well (only to get a warning if the versions do not match)?
This adds buttons for inserting/removing bookmarks and navigate them.
Since the function keys were replaced with the touch bar, there currently is no other way to set and navigate bookmarks other than these buttons so make their visibility priority high.
Since we have multiple application targets, it doesn’t make sense with a global APP_NAME variable.
Though if building the frameworks as standalone bundles and embedding them in different applications, we may need some sort of unique component in the bundle identifier, but we currently do not do this (they are all statically linked, so the Info.plist is currently unused).
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).
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.
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.
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.
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).
Apple has changed the style of borderless controls to use slightly dimmed text color, presumably to use the non-dimmed color when being pressed.
To match this we use the secondaryLabelColor for text, but ideally we should find a solution that does not rely on assumptions about the text color used by the controls.
The feature is currently not exposed via the UI.
To enable set the changeThemeBasedOnAppearance defaults key to YES and assign the darkModeThemeUUID and universalThemeUUID default keys with the desired theme uuids to use in dark or light mode, respectively.
This is to avoid issues with AppKit when changing OakChooser to be a subclass of NSWindowController, as NSWindowController already has a document property and makes some assumptions about this.
I picked TMDocument over oakDocument only because I wasn’t sure how to capitalize the latter for getter/setter.
On 10.14 we use the “behind window” blending mode as we’d prefer the background to differ from that of the text view itself, though I am not seeing much of a difference here.
This both allows updating the captures from outside the text view (e.g. Find dialog) and it uses the correct captures if performing searches in multiple tabs with delayed replacements.
Also, switch to use the new divider styles in most places. The remaining usage of the old "OakCreateLine" functions are in the OakChooser windows. These will be refactor for better dark mode support next.
