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.
If we set ‘plain bold’ then it means that italic and underline are explicitly disabled (should a more general theme rule enable them), but bold is left enabled.
Some targets were including headers from frameworks not specified in their link dependencies. For a clean build this could cause an issue because the header was not available at the time of building the target.
The updated link dependencies are also based on what a target’s tests require. Ideally tests would have separate link dependencies, but as we don’t want to maintain this manually, this will have to wait until the build system automatically handles link dependencies.
Currently the commit command uses constants from the CommitWindow framework but should actually not be linked with it. However, the optimizer will strip dead code, so it should not result in much if any difference in the resulting binary and does solve a build dependency issue.
I mainly dislike the trailing zeroes because CGFloat used to be a float but 1.0 is a double (1.0f would be a float). So better to under-specify and let the compiler figure out the proper type.
This is enabled by adding the following to your theme:
colorSpaceName = sRGB;
The default color space used for themes is “Apple Generic RGB” which is a bad choice for interoperability with other software (e.g. exporting a theme to CSS, creating theme colors in Photoshop, and similar).
Related to issue #768.
Since styles_for_scope effectively ignore the font parameters (and instead return styles based on the font parameters used when the cache entry was created) it is a better design to have theme_t own the font. This way, changing it can do the proper cache invalidation.
A minor downside is that we can now change the font of the theme without also changing the layout’s font, which wouldn’t cause proper layout invalidation — since layout_t owns theme_t though, users of a layout should always change font via layout_t (which will then change it in the theme).
Also, themes cannot be shared between views that wish to use different font settings.
Font name and font size was being used in the cache key as a way to avoid having to do cache invalidation. This comes at a price of a 3X slow down. Instead clear the cache when font size/name changes. Excessive font name/size switching should be deterred IMO, why not with slowdowns? so no real downside. This does not affect themes setting font name/size, as they are handled by another mechanism.
Previously, if no themes were active, the gutter colors would
not be set. This would, effectively, give you random gutter colors
on TextMate startup. (or, sometimes, a completely transparent gutter).
Previously all the colors were calculated so setting e.g. the icon color made it sort of necessary to also set the iconHover and iconPressed color.
Now the default icon hover and pressed colors are a potential user supplied icon color. Likewise, the default icon color is a potential user supplied foreground color, etc.
This removes all the blending, the need to provide a scope selector to obtain them, and no longer taxes the general syntax highlight (by no longer having to carry around a dozen gutter styles per scope).
Use the text foreground color for icons when the theme doesn’t provide a color and introduce ‘gutterSelectionIcons’ for the color of selected icons (defaults to selected foreground color).
Also changed the gutter selection border color to match the divider color (when it isn’t specified by the theme).
Previously if the color for X (where X is e.g. foreground or invisibles) had an alpha value other than 1.0 (fully opaque) it would be blended against the less specifically scoped color for X rather than the background.
There was no real logic behind the previous design other than to treat all color blending the same and it would cause a problem for 1.x themes using transparency for selection or invisible characters.
Closes issue #285.
