10.14/Mojave Dark Mode doesn't change appearance

[balthisar]

I'll take a stab at this in the near future, as I've not contributed anything useful in a few years, and I still use this fork because it's pretty much the best thing out there.

I just wonder what we'd want to do with MGSPrefsColourProperties.xib and schemes. Apple's new guidelines suggest that WYSIWYG content should not switch automatically, e.g., a word processor should continue to show a white page. Fragaria isn't WYSIWYG, however, so I don't think that applies.

Ideally, I would think that we'd want to allow users to select separate schemes for Light Mode and Dark mode, so that the views update any time the system is changed, rather than forcing users to make a different selection.

If that's the case, we could leave the NIB alone, and update two preferences: if the user is in Light Mode and selects a theme or makes changes, then those colors are saved as Light Mode preferences. If the user is in Dark Mode, then colors are saved as Dark Mode prefs.

Alternatively, we could add another drop down list, and say that that's the selected theme for Dark Mode. This kind of complicates the UI, though, because when using the color pickers, which theme list is it applying to?

There's that, and also the gutter that doesn't take the Dark Mode appearance, of course.

[shysaur]

At the moment I do not have access to the developer previews of 10.14, thus I am unable to work on this issue. So any contribution on this front is especially welcome!

About MGSPrefsColourProperties.xib, you're absolutely right about Fragaria not being WYSIWYG. Given that will be both people that stick with just one mode and people who switch modes depending on mood/night-day cycle, having separate preferences is obviously the right choice. I like the idea of having the same dropdown choose both light mode and dark mode depending on the system state.

But this feature can't be handled just in the preferences system, because ideally we would want to support it even if the preferences system is not being used. On the MGSFragaria side, there should be two separate color scheme properties, one for light mode and one for dark mode, which will be selected by Fragaria's code dynamically by listening to the AppleInterfaceThemeChangedNotification. But with the current API that would cause a giant mess of duplicate properties. The color scheme settings should all be moved to the newly-made-public MGSColourScheme, which would still be a kinda messy API rework if we want to keep backwards compatibility (less messy than duplicating all the old properties, but a lot worse on the implementation side of things). I'm unsure about what's the best approach overall here.

[balthisar]

I'm still in the planning phase. Here are my thoughts so far.

• This fork still has a deployment target of 10.7 (Lion, July 2011). Would there be any objection to updating this a little bit, say, to 10.10 (Yosemite, October 2014). This gives access to named NSColors, which is valuable in making some things work automatically.

• Adding NSRequiresAquaSystemAppearance to the application plist and framework plist allows 10.14 to apply Dark Mode, even for pre-10.14 SDK, and of course, this entry means nothing when app/framework used on pre-10.14 systems. I've tested this, and it works. This simplifies things greatly.

• Fragaria nearly works now. The gutter has a hard color coded; changing this to a standard system color should allow it to magically work, too. Some of the other decoration colors are based on this hard coded color, but I'm sure a suitable named color can be used instead.

The points above make Fragaria completely Dark Mode compatible, and is backward compatible, as long as we ignore color schemes.

As for the color schemes and MGSFragariaView default colors.

• I think I'd like to start by serializing NSColor instead of storing the RBG values in the plists. I think I can handle backwards compatibility by versioning the scheme plist.

• NSColor allows the storage of named colors, e.g., the system colors. Thus, converting, say, "Fragaria Classic" to use only named colors (textColor and systemBlueColor) means that, at least, the default scheme will automatically adjust to Light Mode and Dark Mode, no additional code required, and completely backwards compatible to 10.10 (because of, e.g., systemBlueColor).

• Without schemes, we simply make sure that the default colors are all system named colors.

Scheme Management:

• I should move all of the color settings into their own dictionaries in User Defaults, so that we can keep the same key names. So, we can have a AquaSystemAppearance dictionary with schemeName, backgroundColor, colorForAttributes, etc., entries. This keeps everything nicely backwards compatible.

• On SDK10.14 running on macOS10.14, the controller can simply use a different dictionary name, e.g., "DarkMode" with the same key names for colors. This should make it simple to implement, and only a few IFDEF's (to protect building on 10.13 and earlier) and selector checks (to protect deployment pre-10.14) should be needed.

• As long as schemes are being reworked, I'd like to keep track of the schemeName. Currently, the displayed scheme will reflect the first scheme, alphabetically, that has all of the same colors. This is actually the larger pain in the but to manage, because we can set color preferences without updating the scheme name, but I think it's manageable.

• As in the original issue, then, any changes made in Light Mode will be kept in the AquaSystemAppearance dict, and respectively for Dark Mode.

• I do not suggest making all of the built in schemes use named colors. Only the "special" default scheme. Users are free to do as they like, however.

All in all, this looks fairly manageable.

[shysaur]

Would there be any objection to updating this a little bit, say, to 10.10 (Yosemite, October 2014)

No objection; but in that case I will increase the major version number, and take the opportunity to cleanup some details of the API.

apply Dark Mode, even for pre-10.14 SDK

This is not a problem; Xcode 10 is available on macOS 10.13 as well and it links against the 10.14 SDK even on 10.13. After all, Apple basically mandates for everybody to always build with the latest SDK. I would not force dark-mode compliance using NSRequiresAquaSystemAppearance if some user of Fragaria is still using the old SDK when even Apple's APIs don't.

The gutter has a hard color coded; changing this to a standard system color should allow it to magically work, too. Some of the other decoration colors are based on this hard coded color, but I'm sure a suitable named color can be used instead.

👍

As for the color schemes and MGSFragariaView default colors.

This plan doesn't look very good to me because we don't have many system colors to choose from. If in the future somebody decides to upgrade Fragaria Classic to a fancier color scheme or if a new coloring category is added which should have an unique color and we're out of system colors, then we have a problem.

Additionally, I'm not sure about which problem you mean to solve by using a color scheme using named colors. We still want automatic color scheme switching even when using schemes with non-named colors; wouldn't it be easier to reuse the same logic needed for switching across custom color schemes to switch across default color schemes?

Additionally, since using named colors already requires a major version bump because of the minimum OS version change, we can do any API rework we want without worrying too much about backwards compatibility. Thus we can implement the idea of separate color scheme properties, one for light mode and one for dark mode on MGSFragaria without having to hack backwards compatibility in.

Scheme Management:

If I'm reading your post correctly, basically the idea is that in UserDefaults, the color scheme info is moved to a NSDictionary nested like this:

colorScheme
|
+-- AquaSystemAppearance
|  |
|  +-- schemeName = "..."
|  |
|  ...
|
+-- Dark Mode
  |
  +-- schemeName = "..."
  |
  ...

I like the idea; the only real complication will be testing the migration from the old "flat" preferences to the new nested ones.

[shysaur]

The changes discussed here were implemented in #106, and an additional related feature was added in #113.