This provided value during early development, but has been unused for years, and it would generate too much noise if converted to os_log.
So better to just remove it all and add os_log statements as needed.
This was required when we linked each framework as its own thing, which we do not do anymore, and if we do go back to this system, we can simply have symbols public by default.
This partially reverts 6ffd0f2e92
While we do not support transparent themes per se, we still use the alpha colors and thus would previously fill the background using alpha, into a layer that we hadn’t previously cleared.
This does completely remove support for transparent themes, but any recent version of macOS would not support it anyway due to layer-backed views.
The crash resulting from setting opaque is because of recursion: After session restore, the window will calculate shadow, this triggers a “user defaults did change” notification, which updates theme of text view, which sets opaque, which re-calculates shadow and tries to recursively obtain a non-recursive mutex.
Theme is now stored only with OakTextView (observed by OakDocumentView) and the “global” setting is stored in user defaults (not Global.tmProperties), though it is still possible to override theme on a file-by-file basis via .tm_properties files.
This is because OakDocumentView is not in the view hierarchy and it obtains the theme via settings_t, so there is no way to notify about theme changes.
Originally the idea was to store it with the current pasteboard item, so that updating the pasteboard would automatically clear the matches.
But since there is currently only one use-case for this feature, the Find class can simply register for a “pasteboard did change” notification (which it already does for other reasons), and clear the matches if the clipboard changes.
The only downside is that the text view cannot depend on the find framework, as the latter already depends on the former, but we can just import the Find interface, and assert that the class will be present at run-time.
Long-term though, we should refactor this, as we do need two-way communication between these frameworks, for example to make matches live or update the selected match in the Find window when advancing through them in the text view (with ⌘G).
Previously some status bars could be compressed vertically because the dividers did not have a fixed height, so they were sized based on their intrinsic height.
With a fixed height the intrinsic height is redundant and previously it was simply hiding an issue with an under-constrained layout, so better just remove them.
This makes the color of the separator bar better adapt to the color of the status bar and should make things more consistent, as we already have separators inside visual effect views in various places.
Also adjust height of the vertical separators in status bars to only be 15 pixels so that we have equal padding above and below.
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.
