-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
10.14/Mojave Dark Mode doesn't change appearance #105
Comments
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 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 |
I'm still in the planning phase. Here are my thoughts so far.
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.
Scheme Management:
All in all, this looks fairly manageable. |
No objection; but in that case I will increase the major version number, and take the opportunity to cleanup some details of the API.
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
👍
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.
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:
I like the idea; the only real complication will be testing the migration from the old "flat" preferences to the new nested ones. |
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.
The text was updated successfully, but these errors were encountered: