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).
We previously avoided this link dependency because it would cause a cyclic dependency. The build system does however not error on cycles in the dependency graph as they are all statically linked together (rather than dynamically linking with each other).
Only cycles between root targets would cause a problem.
This changes a bunch of things:
1. Each framework now creates its own include directory for exported headers, and any target linking with this framework, gets that directory added to its include search path. This ensures deterministic behavior, unlike previously where a single shared directory was used, so even if target A did not explicitly link with target B, there was a reasonable chance that target B’s headers would be available when target A was built.
2. There is a new IMPORT keyword to indicate that a target depends on the headers of another framework but does not want to link with it. For example the `commit` shell command imports headers from the CommitWindow framework (related to their communications protocol) but linking with the CommitWindow framework would not be practical (as that would bring in all the resources of the CommitWindow).
3. All embedded targets are signed before being copied to their destination.
4. A new CS_ENTITLEMENTS keyword allows specifying `codesign` entitlements. Currently the hardened runtime is enabled, although this does make development problematic, as modifying files of a running instance (as done during rebuild) can cause TextMate to crash with EXC_BAD_ACCESS (Code Signature Invalid). Worse though, it seems the system has a cache of blacklisted executables indexed by inode. So if e.g. the embedded `mate` executable gets blacklisted, one has to manually remove and rebuild it, before it gets possible to use it again (by default, rebuilding causes the inode to be re-used, but I may change the build system to unlink before copy).
5. The build file no longer contains rules related to deployment. Instead variables are declared that a user build file can reference to extend the build with notarization/deployment rules (without having to hardcode build directory paths).
6. The code has been made modular with a Compiler super class that is subclassed to add support for file transformations (xib, ragel, asset catalogs, etc.) and a transformed file can have its own settings.
7. If target A links with target B, the linker flags of target B will now be included when linking target A.
8. Currently no indexing of help books. Unsure if this is actually useful.
9. Previously it was possible to have umbrella targets that would not generate any output, but just change settings for their sub-targets. This is no longer supported, as the implementation was arcane. I would like to introduce a different system for managing sectioned settings. Related to this; settings in target files are now always merged, regardless of whether using ‘=’ or ‘+=’.
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.
