OakSyntaxFormatter now applies background colors only when they do not match the theme's global background color. The old behavior drew the background all the time, which looked off when drawing formatted text in the Find History list. This effect is made especially apparent by macOS 10.14's translucent combo boxes, and now that they're used for history in the Find dialog, this needed to be fixed.
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.
Newer versions of clang now warn when using API's that are only available on OS version newer than the target OS unless they are guarded using `@available`.
This is temporary and should be remove when we move away from older versions of Xcode.
This introduces the `OakBackgroundFillViewStyle` enum with styles that are dark mode aware and should lead to more consistent use between UI elements in the future. Also, convert OTVStatusBar and OFBHeaderView to use the new style enum.
We remove all styles from the string, even when styling is disabled, as these styles could be from when styling was enabled, so we can’t trust them to be proper defaults.
However, a string with no styles will be rendered as black in the interface, rather than using the default text color for the interface, therefore we now explicitly set the string’s foreground color to be the control text color.
The default is to wrap text, which could happen when installing a replacement font.
Specifically installing https://github.com/jenskutilek/FiraSystemFontReplacement shows a problem for menu items using ⌃⇧ in their shortcut key.
My theory is that the font lack these glyphs and font substitution can take them from different fonts, and thus, sometimes they would render as narrow, other times in regular width.
It appears that when we measure the string width, and use for the cell’s width, we get the narrow glyphs, but then when rendering the text, the wider glyphs are used, causing the text to overflow and thus wrap.
This does mean that we are taxing our main thread with disk access. This is mainly a problem for users who are using network mounted file systems, but it does provide better abstraction in the code, and should this turn out to be a performance issue, I think a better approach is to fetch the tags in a dispatch queue (initiated by FSItem), and then use KVC to update the property once the tags have been loaded, although ideally such system would use some sort of batching, so that we do not dispatch in each property accessor.
Could also have the background directory scanner set a boolean property to indicate if the item has tags, as most items do not, and in that case, we can bypass the disk access. But this then only does half the job of encapsulating how tags are stored.
The rationale behind the latter is for consistency with pointer declarations, e.g. we need to do `NSString* const kConstant = …` to indicate that the variable is a constant NSString pointer, so for this reason I prefer to also do `CGFloat const kConstant = …`
This commit can be merged into its parent.
The advantages are:
- More compatible with version control
- Easier to copy/paste menus and menu items between other projects
- Easier to setup menu delegates or obtain pointers to menu items
- We can use symbolic names when setting a menu item’s tag
- More transparent: We can read the declaration in a few minutes, use search, etc.
There are two disadvantage that I can think of:
1. We currently need to use private API to create the Open Recent submenu. Should this become a problem in a future macOS update, we can always create a single Open Recent menu in MainMenu.nib and use that when building our menu.
2. If you make a typo in the menu declaration then the compiler error will often just point to the first line of the declaration rather than the line with the incorrectly declared item. One can comment out sections to narrow it down, if many edits have been made since last compile.
Comment also added to the source (since this workaround is not optimal, and I would like to find the correct solution):
If we use `self.size` for the off-screen image buffer then we get a scaled up 16×16 image in the file chooser (⌘T).
My theory is that when drawing the image, the image size is 16×16 but the graphics context uses a transformation so that each point is multiple pixels, which our off-screen image does not replicate.
I do not know how to get the actual “pixel size” of the destination, so using the largest image is a workaround and knowing the actual size could give a better result.
Most of these layout changes are related to the common pattern we used to set constraints for "dividers", where one of the dividers is specified to be connected to both edges of its superview then setting the other dividers' constraints to have equal widths (e.g., @"H:|[divider(==divider2,==divider3)]"). On 10.12, this now appears to result in ambiguous layout. We can resolve it by connecting at least one of the edges for each divider to its superview.
Although this is actually deprecated in 10.10, new APIs are available in 10.9 and it will make addressing deprecation warnings when upgrading to 10.10 easier.
Although this is actually deprecated in 10.10, new APIs are available in 10.9 and it will make addressing deprecation warnings when upgrading to 10.10 easier.
