Accent color on settings portal

[lleyton]

Accent Colors

Introduction

Accent colors provide a way for users to personalize their desktop in a simple, developer-friendly, and effective way. Throughout the community there has been a general interest in the inclusion of accent colors within apps and desktop environments. This proposal aims to standardize an accent color key on the Settings portal.

Details

A new key on the Settings portal, accent-color, would be defined under the org.freedesktop.appearance namespace. The value of this key is a variant. In the case that an accent color is requested, the underlying value would be a struct containing three doubles, each being an RGB value in the range of [0,1]. Whereas, if the user has no preference or wants the application to use their own branding colors, the type will be a uint32 with the value 0, representing no preference. Clients may consume this value in order to style their user interface using the requested accent color. Clients should handle an unknown value in the same way they would handle a "no-preference" value.

Implementation

A reference implementation of the client can be found in tauOS's libhelium. I have also forked xdg-desktop-portal-gnome adding support for the accent-color key.

Signatories

• Lleyton "Lea" Gray, Fyra Labs
• Paulo "Lains" Galardi, Fyra Labs

Acks

• @alice-mkh (GNOME)
• @JoshStrobl (Budgie)
• @Sodivad (KDE)
• @jackpot51 (Cosmic)
• @danirabbit (Elementary)

Related PRs

GNOME: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/82, https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/63, https://gitlab.gnome.org/GNOME/libadwaita/-/merge_requests/824, https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2715, https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1728
Budgie: waiting for BuddiesOfBudgie/budgie-desktop#428
KDE: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/182
Cosmic: TODO
Elementary: elementary/settings-daemon#60

[TingPing]

We need to discuss this with the various desktops.

It was mentioned as an idea on #gtk that this could be a named color, such as blue rather than specific RGB values. This would be more flexible and supportable by various designs.

[emilio]

It'd be great if there was a pair of colors (accent color + accent color text) or something like that to ensure that you can put stuff on top of the accent color without missing contrast, see w3c/csswg-drafts#7347 for some similar discussion.

[emilio]

(you can always delegate the foreground color computation to the app but that's likely to cause inconsistencies)

[alice-mkh]

In libadwaita we also have a separate color for accent-colored text or icons on top of a neutral color, because it was next to impossible to ensure contrast for those otherwise (without making foreground text dark by default).

For comparison, using the same color for both:

Though we probably could get a decent result with calculating one color from the other one if it's programmatic (when this was implemented, it had to be done with css alone)

[lainsce]

The idea is that this key would give you the client a color to use to programmatically implement in your side for your needs, so that list of colours could all come from a single color.

[lainsce]

Indeed, but the key would only give you an accent color; if your platform does accent color-based background/foreground tinting, then this would be the color to tap into for that.

[danirabbit]

I agree with @TingPing and @Exalm that named colors would be better. We use several shades in elementary OS to account for dark mode, background vs foreground, etc and ensure contrast.

For reference, we’re currently using Red, Orange, Yellow, Green, Teal, Blue, Purple, Pink, Brown, and a chromatic grey.

[lainsce]

For reference, in libhelium we're using:

Red, Orange, Yellow, Green, Teal, Blue, Purple, Pink.

[nothingneko]

What is being used in Plasma, Ubuntu, and planned in GNOME?

[dominichayesferen]

Regarding the colour names idea... In my opinion the standard itself should be able to use the full RGB 255255255 colour set, even if it means being technically breakable.
BUT that the DE should be allowed to severely limit the selection of accent colours to specified colours, with matching specified foregrounds, if it so chooses.

@jadeastar Plasma uses colour schemes (in its GTK stylesheet it uses CSS rgb values set onto its own in-stylesheet CSS variables that it uses to colour controls), and Ubuntu changes the GTK stylesheet to different Yarus, if I recall correctly.

[nothingneko]

I meant a list like Danielle's comment

[dominichayesferen]

I meant a list like Danielle's comment

That's a tough one. KDE Plasma is technically 255x255x255 possible colour schemes, but if you were to limit it to the selection they supply if you 'turn on' accent colours in more recent releases:

HOWEVER, distributions like Feren OS add their own accent colours below those, so it isn't a perfect representation in the slightest.

As for Ubuntu:

If you need them, I could go and get the exact colour codes later.

[swick]

FYI, an RGB triple isn't a color; it only becomes one if it is associated with a color space.

[alice-mkh]

planned in GNOME

Nothing - this wasn't discussed in GNOME.

[nothingneko]

planned in GNOME

Nothing - this wasn't discussed in GNOME.

I thought there was some kind of plan, thanks for the correction

[dominichayesferen]

Also, given the mention of colour names as an idea... here's a problem with that idea:
Colour inconsistency across applications.

To a developer looking to implement that, how do they know which exact colour 'red', 'orange', etc. is? There wouldn't exactly be any set standard on shades or anything of that sort, so they'd be essentially forced to take creative liberties.
While this would be good on a branding standpoint, it'd ruin accent colour usage consistency in the process.

Also, if there's one other reason to support rgb accent colours: It's the easiest parallel to, or exactly, how applications, in literally every popular OS that has accent colours, follow the accent colours. (e.g.: Windows uses what used to be called Window Colours, which are stored as either RGB or BGR (backwards RGB) codes in the Windows Registry)

Edit: Additionally, wouldn't making them names be more tedious for DEs like KDE Plasma to implement than, say, #rrggbb?

[alice-mkh]

I thought there was some kind of plan, thanks for the correction

Some vague plan - sure. But in general - coming to GNOME and other desktops to discuss this was the job of the people backing this proposal. Preferably before opening a PR too. Literally the only reason I know about it at all was because of a random accent color discussion in #gtk room and lains mentioned there's now a proposal PR.

There's also no agreement on design side accent colors are needed at all, so talking to designers should have been the first step.

To a developer looking to implement that, how do they know which exact colour 'red', 'orange', etc. is?

That's up to them. They usually have a palette they can use to figure this out. Firefox, Telegram etc all have their own palettes.

in literally every popular OS that has accent colours,

Not in macOS, for example, no.

Edit: Additionally, wouldn't making them names be more tedious for DEs like KDE Plasma to implement than, say, #rrggbb?

And making them an arbitrary rgb would make it more tedious for DEs like GNOME and elementary to implement it than named colors. elementary can't even set arbitrary colors atm, and GNOME needs to calculate additional colors (as mentioned in #815 (comment))

---

But anyway. There's no point in arguing about specific approaches until you have the requirements from all sides collected. That hasn't happened yet.

[nothingneko]

@Exalm macOS does have accent colours and has since Catalina

[danirabbit]

Sure there’s a problem here because using arbitrary color values would be basically DOA for ensuring any kind of color contrast, but using names colors would mean apps built against different platforms would have slightly different interpretations of what “orange” (for example) means. But I think the latter is ultimately more usable

[alice-mkh]

@Exalm macOS does have accent colours and has since Catalina

I didn't say that it doesn't. In fact, it has them since Mojave, not Catalina.

But they are represented as an enum, not an arbitrary color: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/rendering/RenderThemeMac.mm#L205

I don't see that enum in their docs though, so I'm assuming it's semi-private API.

[nothingneko]

Sure there’s a problem here because using arbitrary color values would be basically DOA for ensuring any kind of color contrast, but using names colors would mean apps built against different platforms would have slightly different interpretations of what “orange” (for example) means.

I think this won't be a huge unless the colours are hugely different.

[nothingneko]

@Exalm macOS does have accent colours and has since Catalina

I didn't say that it doesn't. In fact, it has them since Mojave, not Catalina.

But they are represented as an enum, not an arbitrary color: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/rendering/RenderThemeMac.mm#L205

I don't see that enum in their docs though, so I'm assuming it's semi-private API.

Thanks for the clarification and correction! I misunderstood you initially.

[dominichayesferen]

Sure there’s a problem here because using arbitrary color values would be basically DOA for ensuring any kind of color contrast, but using names colors would mean apps built against different platforms would have slightly different interpretations of what “orange” (for example) means. But I think the latter is ultimately more usable

I mean, if we add the ability for the DE to set an accompanying accent foreground too, that would be one thing sorted* already. Fortunately, we do have means of brightening and darkening colours in most toolkits on-the-fly, such as GTK's darken and lighten, but I do fully understand the desire for names.
However, I am also conscious about the limited scope it brings. I feel that limiting the scope on a DE level instead would be the happier medium for users, and would therefore allow equal accent colour control to that seen in Android 12+ and Windows for example.
But, we can always talk about the specifics more once more people are in here.

*Edit: partially sorted

[orowith2os]

Is there anything blocking this now? AIUI it's just toolkit implementations, and someone to get the appropriate portals to expose it. Nothing that's blocked other portals before.

[JoshStrobl]

@orowith2os is currently working on a proposal for an XDG desktop portal for Budgie Desktop and requested an official ack from me. Budgie Desktop is intent on supporting an Accent Colors portal and expose arbitrary value, similar to the intent by KDE folks (rather than libadwaita appeasement). This would enable KDE application colors to be aligned with future accent color choices by Budgie Desktop users.

It is disappointing to see that calls from folks like Nate in KDE on expanded capabilities for implementations and users be rejected by GNOME:

Arbitrary colors are not happening, period. At that rate this won't happen at all.

This will create visual inconsistency between applications of varying toolkits and vendors. I would highly encourage GNOME get on-board with the idea of supporting "arbitrary values", which will more greatly increase implementation flexibility and user choice.

[jadahl]

@JoshStrobl Been trying to gather "acks", and trying to derive that from your above comment, and
the conclusion from the Matrix room is that you're acking the current proposal in this PR. Let me know if that was in error.

[orowith2os]

We can keep any arguments for GNOME to support accent colors to the GNOME channels, and discuss with the design teams there (it already has been, afaict - do with that what you will). Let's not clog this up with any more named colors vs arbitrary colors arguments; we've had enough of that, and the general path will be for each desktop to decide how they want to implement this, with an arbitrary color being the way for applications to read the accent color.

[Sodivad]

Looks ok for me from a plasma side and with the invalid color possibility we even have an escape hatch if we dont like it :D

[dominichayesferen]

So, wait, at this rate is this merge request simply not merged yet because of waiting for DE implementations, or...?

[jackpot51]

COSMIC approves of this interface.

[orowith2os]

@dominichayesferen just acks, the implementations can be done whenever the appropriate parties would like

[dominichayesferen]

Pardon the idiocy, and to put some context for anyone else reading this in the future who's also likely wondering this, but what are 'acks' in this context again?

[JoshStrobl]

Pardon the idiocy, and to put some context for anyone else reading this in the future who's also likely wondering this, but what are 'acks' in this context again?

Acks are acknowledgements. Intent with acks is to communicate support or knowledge of this proposal 🙂

[danirabbit]

Hey, just wanted to say that yup we merged Alice’s PR on our portal side so Pantheon is already good here and although it’ll take a bit more of a rework we’ll figure out the granite end so granite apps can support this as well. Thanks everyone!

[TiZ-HugLife]

I would highly encourage GNOME get on-board with the idea of supporting "arbitrary values", which will more greatly increase implementation flexibility and user choice.

You, me, everyone discussing in this thread, and everyone just reading this thread trying to stay informed, all know that this is not ever going to happen. I think that when it comes to accent colors, and other such things you want users to be allowed to define freely, it's not productive to hinge discussion on the participation and acknowledgement of platforms that do not want users to have those sorts of choices. The onus should be on restrictive platforms to adapt their implementations of permissive specifications, not on permissive platforms to convince restrictive platforms to allow their preferences to exist at all.

This is one single facet of visual customization that has been stalled for over a year. One single color choice. And Dominic wants to create a further spec for a more wide definition of color scheme like Windows Classic. GNOME will not support that spec, and will not want anything to do with it. And a lot of evidence--particularly the discussion you linked--indicates that they didn't even want anything to do with this! And that's after non-participation has blocked discussion on this for such a long time.

What I don't understand is why you want GNOME's approval and participation here. Your goals and theirs are diametrically opposed, and you don't need them. Plasma, COSMIC, and Tau all want user-definable color expression, so why does it matter that GNOME doesn't? They also didn't want decorations in Wayland, and they also didn't want tearing in Wayland. And those things happened without them anyways. GNOME doesn't have them, but they still exist. GNOME should be allowed to make an environment and an application ecosystem that chooses to be restrictive in the name of creating a precisely designed user experience, but that shouldn't affect the rest of you.

[GeorgesStavracas]

Let's do it

[lleyton]

We are so back.

[nothingneko]

Sláinte! Thank you all for your excellent work! Excited to see this implemented!

[dominichayesferen]

Congrats on getting this merged!

[easyteacher]

Hi, please be kind to open source project maintainers.