#453 Use "New Fedora Blue" for accent color
Closed: Won't fix 24 days ago by mclasen. Opened 7 months ago by mattdm.

Now that GNOME upstream allows this, could we use the Fedora blue by default? This is #51a2da in sRGB.

Additionally, it would be nice if the color palette offered in Settings were from the official Fedora design guide color set.

Screenshot_From_2024-11-01_10-52-23.png


Is the palette even customizable? I didn't think it was...

Metadata Update from @ngompa:
- Issue tagged with: experience

7 months ago

Metadata Update from @ngompa:
- Issue tagged with: meeting

7 months ago

Metadata Update from @ngompa:
- Issue untagged with: meeting

7 months ago

Is the palette even customizable? I didn't think it was...

No, I didn't think it was either...

Yeah, it looks like the palette is not customizable, nor can you use direct color values in the GNOME implementation of accent colors. At least that's based on the merge requests I've looked at starting from the gnome-control-center one.

So, unfortunately this is not possible.

Metadata Update from @ngompa:
- Issue close_status updated to: Can't fix
- Issue status updated to: Closed (was: Open)

7 months ago

Ubuntu does patch libadwaita to use their colors instead of the GNOME choices.

This feels like a throwback to 15 years ago, when distro-colored folder icons were all the rage.

Ubuntu does patch libadwaita to use their colors instead of the GNOME choices.

I'm going to re-open based on this. Surely we can use this, and hopefully convince the upstream that ... people really want it.

This feels like a throwback to 15 years ago, when distro-colored folder icons were all the rage.

Eh, maybe? But since there are colors, let's make them on-brand.

Metadata Update from @mattdm:
- Issue status updated to: Open (was: Closed)

7 months ago

I believe the current status is that if you patch libadwaita, Flathub Flatpaks will still use the default GNOME colors.

I remember that allowing distros to tweak colors was a consideration when GNOME's accent colors implementation was being drafted, but it's not really part of the initial GNOME 47 implementation.

I wasn't involved in the accent colors work so don't have a huge amount of insight into the decisions that were made there. That said...

Historically any discussion of colour customisation quickly became a tug of war between distros, app developers and users. I don't think it's possible to have a design which satisfies everyone, at least with the technology we have today. I would check with the upstream developers to see what repercussions there might be when changing the accent downstream.

In terms of the specific colours, I know that the default accent colour palette was selected in order to ensure good legibility when used as a background for white text (an example ). The Fedora blue is lighter than the default and brings the contrast ratio down from 3.8:1 to 2.8:1. The GNOME blue has an A WCAG rating. The Fedora blue fails the WCAG test. My contrast checking app says "This colour combination doesn't have enough contrast to be legible."

Maybe extending the accent option to include one optional distro specific color, ie so that distros can put a file with a color code somewhere that the UI picks up should be a feasible option here I would think, and then distro has a proper way of doing this instead of downstream patching.

Allans point about contrast is a valid one though so maybe even if we got this as an upstream option it wouldn't be a great choice to just pick the standard Fedora color, but we could maybe do a darker tone or maybe Red Hat Red (not sure Red Hat red though is materially different than the current Red)

This would be difficult with the current GNOME color accent architecture though, wouldn't it? As far as I know, even though the APIs technically allow arbitrary color values, GNOME's implementation does not. And it wouldn't work in Flatpak'd applications because of that, since there's no way to propagate and color based on a color code for GNOME apps.

This would be difficult with the current GNOME color accent architecture though, wouldn't it? As far as I know, even though the APIs technically allow arbitrary color values, GNOME's implementation does not. And it wouldn't work in Flatpak'd applications because of that, since there's no way to propagate and color based on a color code for GNOME apps.

I haven't had anyone explain the exact architecture to me, but this seems like something that should be resolvable somehow. I mean obviously it is not doing today with no changes, but I want to understand why/if it would be a major re-architecting to add a feature like this.

It was intentionally designed to prevent distros from customizing the accent colors. This is a social problem, not a technical problem. We will just have to patch it if we want to change the color.

Maybe extending the accent option to include one optional distro specific color

From a UX perspective having two blues or two oranges would be a bit odd.

Fedora should just stick with the upstream colour set, imo.

This suggestion of mine is likely going to be controversial, but how about making org.gnome.desktop.interface/accent-color accept hex triplets in addition to the predefined color names?

It doesn't have to be exposed in the Settings app, so the less-tech-savvy users wouldn't get themselves a footgun, whereas both distros and tinkerers would be happy. A win-win scenario, methinks.

@hasshu this is not something we would want to carry downstream. So the conversation needs to happen on the libadwaita channels, not here.

By definition, this would be a downstream change, so I'm not sure what there is to discuss.

By definition, this would be a downstream change, so I'm not sure what there is to discuss.

The support for custom/vendor-specific accent color should be implemented upstream IMO. I don't think we should just pick a color to overwrite downstream.

Sure, but if it didn't happen when Ubuntu needed it, I'm not sure what we can do to make it possible for us upstream.

this is not something we would want to carry downstream. So the conversation needs to happen on the libadwaita channels, not here.

@feborges I see your point, but I agree with Neal here: if devs of a prominent distro weren't heard in the end, then a random individual's chances are even less slim.

This suggestion of mine is likely going to be controversial, but how about making org.gnome.desktop.interface/accent-color accept hex triplets in addition to the predefined color names?

This seems perfectly fine to me.

We have two options:

  • Ask upstream to do this and see what happens. I suspect the answer will be "no," but maybe there will be some explanation or path forward.
  • Carry a downstream patch forever, and accept that it only works for Fedora content and not third-party content like anything from Flathub

The future is pretty clearly Flathub, so I'd say trying to go our own way is pointless.

Upstream says "we intentionally went with fixed colors so that apps have tangible targets" and seems pretty disinclined to compromise. I'm inclined to stand down and close this; doesn't seem worth patching downstream?

I agree. This was discussed and rejected with reasons.

Metadata Update from @mclasen:
- Issue close_status updated to: Won't fix
- Issue status updated to: Closed (was: Open)

24 days ago

@mclasen Hold up, chief, no need for upstream to be leaking here.

What would be the harm in a somewhat hidden, and not-really-supported-officially option used downstream?

It's not going to work properly unless you (a) don't care about upstream Flatpaks, or (b) manage to convince the GNOME runtime maintainers to patch their libadwaita, which seems very unlikely.

Carrying downstream patches just to change the shade of blue used in libadwaita apps distributed by Fedora, but not all the other libadwaita apps that you use, does not seem very useful. And we try not to carry downstream patches as a rule.

@catanzaro Fair enough, I guess... If I may ask, since you've been in touch with libadwaita devs, what's the reason behind such vehement opposition?

My best guess is spite. Upstream doesn't like distros and doesn't want us configuring things. It's hard to think of legitimate reasons to block us changing the colors in a color preference.

It's possible to make bad color choices that would break UIs, but I don't think that's a legitimate justification since it's also possible to algorithmically detect bad choices.

Do we have a sense of how complex a downstream patch would be for us? If it's comparable to the Ubuntu one this still seems worth considering IMO, even if it'd only apply to apps we distribute. It might even be helpful because it only applies to apps we distribute, as it'd make them clearly differentiated.

Do we have a sense of how complex a downstream patch would be for us?

Probably one line, to change the blue from one value to another.

If it's comparable to the Ubuntu one this still seems worth considering IMO, even if it'd only apply to apps we distribute. It might even be helpful because it only applies to apps we distribute, as it'd make them clearly differentiated.

I suspect users who notice the difference will most likely just be annoyed by it.

Do we have a sense of how complex a downstream patch would be for us?

Probably one line, to change the blue from one value to another.

If it's comparable to the Ubuntu one this still seems worth considering IMO, even if it'd only apply to apps we distribute. It might even be helpful because it only applies to apps we distribute, as it'd make them clearly differentiated.

I suspect users who notice the difference will most likely just be annoyed by it.

In that case we would take ownership for contrast issues introduced by the new color. If people think that's not a real issue, then I guess the downstream patch would be harmless and just an annoyance for some indeed.

Log in to comment on this ticket.

Metadata
Attachments 1