By implementing this, we avoid potentially updating the menu when pressing “menu keys”, which can be slow due to collecting information about system applications, such as supported file types, icon, and display name.
This would happen when opening the menu via the file browser’s action menu, and then using arrow keys in the text view. On my setup, moving the insertion point was slowed down noticeably.
While in theory just a wrapper for VNODE events, there are some edge cases:
- Observe missing file: Report when created (observe all ancestors to know).
- Rename ancestor: Treat as rename (observe all ancestors to know).
- Move observed file to trash: Treat as delete (reported as rename).
- Rename file with symbolic link in path (e.g. /tmp): Preserve symbolic path.
- Delete observed file and write new one: Treat as a write (reported as delete).
- Rename observed file and write new one: Treat as a write (reported as rename).
- Change case of file: Tricky on case-insensitive but preserving file systems because newPath != oldPath but both exist, so it looks the same as “rename and write new file” (previous case) that should be reported as write.
There is also an issue observing a symbolic link, here we should really observe both the link itself (does it get renamed or deleted) but also the resolved path (does this file get updated).
Currently though this is NOT implemented.
Since we no longer have a shared directory for all the framework headers, we need to either explicitly list each header directory in the compiler flags (or TM_SYS_HEADER_PATH) for header completion and quick open to work, or we need to create a dummy directory with symbolic links.
Previously I was using the previous method, but include folder has to be created when building on a new system, and it doesn’t avoid having to update the symbolic links if we add/remove frameworks to the project, so listing them all in the .tm_properties, while not ideal, is a better solution.
We setup a default in default.tmProperties but incase file chooser code is used outside of TextMate then no such default is found, and the file chooser defaults to excluding everything.
This is a subclass of NSTitlebarAccessoryViewController so it can be added directly to windows as an accessory view controller.
It is key/value bindings-compliant for its properties, which should be bound directly to an NSArrayController, which will make the tab bar view reflect the objects managed by this array controller, including updating the tab bar view when object properties such as title or modified state changes.
The property returns NSNotFound when there is no selection. This seems to be consistent with NSArrayController’s selectionIndex (but inconsistent with many other views, like NSTableView, which return -1 when there is no selection).
While AppKit identifiers are generally strings, which have more flexibility, I think this is mainly because NSUUID was introduced later, and for tab items, identifiers must be unique, which is not enforced (or implied) when using strings.
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.
This is instead of the more opaque OakCreateHorizontalLine(OakBackgroundFillViewStyleDivider).
Also use NSLayoutFormatAlignAllLeading with the visual format language instead of manually creating constraints for the dividers.
Previously it was a subclass of OakBackgroundFillView which adds the NSVisualEffectView as a subview, but this messes up compositing in some cases where an ancestor view is also an NSVisualEffectView, for example when placing the file browser in a “source list” split view item (using NSSplitViewController).
Also change the material to NSVisualEffectMaterialTitlebar. I think this looks better, as the previously used NSVisualEffectMaterialHeaderView does not look identical to other table view headers and only have very faint bottom border but very noticeable “within window” compositing.
A further advantage of changing to title bar material is that NSVisualEffectMaterialHeaderView requires macOS 10.14, so by using title bar material, we avoid having a different code path for users using older versions of macOS.
Previously we would only do this on macOS 10.14 and later, but as we now also use “within window” compositing for the header view prior to macOS 10.14, we should always inset the scroll view.
Furthermore, even without “within window” compositing, insetting the scroll view should not cause any issues, so the code was actually not required previously.
This is to make it easier to support Cocoa’s native resume feature, as for this, we should keep all state in the controller, but also, the controller should be able to know if view state changes, for example expanded/selected items in the outline view, which require our controller to be the delegate.
This is because third party framework headers are likely to be installed in directories with many other headers that can clash with some of our custom frameworks.
Closes#1441.
We now do all the work in NSMenuItem’s setActivationString: and no longer require subclassing the mutable versions of NSAttributedString.
It should now be more transparent what the code does and why it does it.
Starting with macOS 10.15 the system will use new NSAttributedString API to obtain bounding rect, so we need to (also) overload this to return our fixed bounding rectangle.
We don’t care about the trim mode as nobody is reading the generated HTML, but we have to supply something, previously we enabled everything, which is now giving an error despite the documentation saying that trim mode can be “one or more of the following modifiers”:
% enables Ruby code processing for lines beginning with %
<> omit newline for lines starting with <% and ending in %>
> omit newline for lines ending in %>
- omit blank lines ending in -%>
It would seem that ‘<>’ is mutually exclusive with ‘-’ so now we pass ‘%-’ for trim mode.
