Get prefers color scheme from accountsservice

[danirabbit]

Create a Granite.Settings class like Gtk.Settings. Fixes #276

Read-only is intentional as we don't want apps setting this for the user

[cassidyjames]

I think we'll want to switch this to an enum since elementary/default-settings#166 was merged.

[danirabbit]

@cassidyjames Updated. This should work with the new accountsservice stuff.

Since there's no system UI for this yet, you can send this in dfeet "io.elementary.pantheon.AccountsService", "PrefersColorScheme", GLib.Variant("i", 1)

I guess there's a question of how should we demo this? I think we want the override here for the demo maybe? Or should we remove that toggle?

Also, we currently only include this for accountsservice in Odin. Should we add this in Hera too? Maybe not necessarily exposing the setting yet, but if it exists in Granite and AccountsService we could start testing it

Is it okay to make this a boolean property or should we make this enum out of the box? The boolean is nice because you can super easily bind this to app-prefers-dark right now. But this doesn't account for any prefers-light. I guess if we decide to support that we can come back and deprecate the boolean property?

[cassidyjames]

I guess there's a question of how should we demo this? I think we want the override here for the demo maybe? Or should we remove that toggle?

I think we default to the user preference but still allow a local override (so devs can still test how widgets look without changing their whole system preference)? But we can think about it. Another option would be to implement what we expect to see in apps like Code or Terminal where we might want to allow for a tri-state of light/dark/follow system.

Also, we currently only include this for accountsservice in Odin. Should we add this in Hera too? Maybe not necessarily exposing the setting yet, but if it exists in Granite and AccountsService we could start testing it

Yeah I think we include it in Hera. I think I'd like to ship the system UI stuff for 5.2 if possible, because it has been a long time coming and would be a nice preview of the bigger dark style stuff for 6.0.

Is it okay to make this a boolean property or should we make this enum out of the box? The boolean is nice because you can super easily bind this to app-prefers-dark right now. But this doesn't account for any prefers-light. I guess if we decide to support that we can come back and deprecate the boolean property?

Yeah I think boolean is fine and we can deprecate later if/when we expose a light preference.

[cassidyjames]

Hmm, I guess this raises the question of how apps should bind to it. If it changes live, I imagine we'd want the app to change instantly, too. But if they offer an override, how does that interact? I think that's where it has to become a tri-state of:

• Follow system preference
• Always light
• Always dark

Which is similar to what I see in Android apps fwiw. I think most apps that support a dark style should just automatically follow along with the setting and not offer up any sort of UI for it, though.

[cassidyjames]

I guess I'm fine in general with this as a starting point, we can always iterate. I would like to get a review of the code side from someone more familiar and opinionated about Granite and namespacing and everything, though.

[tintou]

It would probably make it clearer indeed to return an enum instead of having a boolean, that way we can extend it without fearing API breaks

[cassidyjames]

@tintou see: elementary/default-settings#167 (comment)

We should decide on unsigned or signed and then make sure it matches in the master and hera branches of default-settings as well as here.

Edit:

enums are int when flags are uint in Vala
that's their standard GVariant type
…
Otherwise we end-up with annotations like this https://github.com/elementary/switchboard-plug-display/blob/master/src/Interfaces/MutterDisplayConfig.vala#L36
—@tintou

[cassidyjames]

Works as advertised. Thanks for hooking up the changes as well to demo how apps can do that!