Comments (4)
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.
from fragaria.
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
andsystemBlueColor
) 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 withschemeName
,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.
from fragaria.
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.
from fragaria.
The changes discussed here were implemented in #106, and an additional related feature was added in #113.
from fragaria.
Related Issues (20)
- Scrolling is stuck after changing layout HOT 13
- Does it support JSON highlighting?
- Add configuration for brace matching. HOT 2
- Additional syntax properties HOT 10
- Fragaria instances sharing the same text storage also share the same text color HOT 5
- Hand-editable color themes
- Color well enabling does not work if the associated "coloursX" property is on global scope HOT 3
- Allow registering in the global preferences controller
- Make it easier to add/remove MGSFragaria from a preference group
- Preferences groups should not retain the Fragarias they contain
- Podspec HOT 3
- DIFF highlighting (feature request) HOT 1
- code folding support HOT 1
- support for different fonts (family, trait & size) in highlighter HOT 4
- Fragaria with Storyboards HOT 1
- MGSSyntaxController get file extension based on a given name. HOT 2
- References frameworks are missing '@rpath/Fragaria.framework' HOT 1
- Custom Auto Complete Words HOT 1
- Autocomplete only when selecting a value from the suggestions list? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fragaria.