GNOME's Platform Design Continues Evolving From Dark Mode To Toasts

[oiaohm]

The WCAG thing about fitting in colour-blindness is interesting, but largely irrelevant to user themes. Yes, it is a huge matter for applications or websites that are hardcoding their colouring irregards of user preference. But for user themes, a user with colour-blindness can choose to avoid colour-blind-unfriendly themes and pick a high-contrast one freely right?

Its not that simple. You need to know when you are choosing a color blind incompatible theme.

https://www.vox.com/2015/2/27/8119901/explain-color-dress

Its the color of dress problem where you vision changes based on time of day and lighting conditions. This is one of those horrible traps all humans at some point have some form of color blindness. This is just the way humans are constructed.

libadwaita / granite / whatever widget library shouldn't encourage hardcoding colouring into themselves. The original problem of apps failing in custom user themes is due to applications mixing use of hardcoded colours and "system colour" / theme colour and put too much assumption into the system colours / theme colours unknowingly. But now, they seems to be putting "The background colours of container widgets are lighter in light mode, and darker in dark mode" into executable binary, instead of static stylesheets. Whether buttons shall be flat and borderless should also be decided in stylesheet, not hardcoded in library. (An application may explicitly say "this specific button shall be flat / non-flat", but it should only be done for special cases, not as general design.)

If some applications hardcode some colours but not all and then cause issues in blending in desktop user theme, such programs may need some compatibility mode to circumvent their bugs, but it is still application bugs, not the fault of non-default user theme. Gnome's decision is equivalent to putting every applications in their camp into a perpetual compatibility mode. It is a lot worse than putting "WON'T FIX" onto any bugs that involved non-WCAG-compliant themes.

This also skips over the fact distributions have been patching in their own theming extensions to GTK3 and going to do this to GTK4 and not working with upstream. So after distributions patch GTK they then patch the GTK provided themes sometimes screwing it up. So now its harder to spot user using a non-WCAG-compliant theme.

This is also only part of libadwaita https://adrienplazas.com/blog/2021/0...ibadwaita.html they talk about it here.

Implementing the HIG is a lot of manual work for application developers. This led to lots of verbose copypasted UI code, full of slight interpretation variations and errors, making applications hard to maintain and full of visual and behaviorial inconsistencies.

As well as addressing the theming problem there is a need reduce the number of issues application developers make when implementing HIG. libadwaita goal is to get rid of some of this code duplication that causes these errors as well.

billyswong the reality here is there is a lot of wrong. There is wrong from gnome, There is wrong form distribution developers and There is wrong from applications developer and lack of guidance to end users all these things have been screwing up end users.

The reality here is the fix does not have gnome developers, distributions developers and applications developer with some level of unhappy because they have to fix things the fix is not really fixing the solution at hand.

Yes visual and behavioural inconsistencies the application developer did really intend todo happens due to coding errors using gtk, EFL, qt, MS windows default toolkit.... So there is need in this department for better tooling to tell developers hang on what you coded here in your UI does not quite look right have you typoed this. Same as needing tooling to validate themes.

Yes gnome core developers are attempting to solve a problem that need solving. I person are not sure they are 100 percent going about it the right way. Yet you have to also remember we know distributions have been extending gtk to add the theming features they want and so call fixing gnome so it useable for end users to have a market advantage.

Yes distributions have so called being fixing gnome for their end users and not submiting that upstream to give themselves a competitive advantage over other distributions. Of course this leads to gnome upstream seeing no reason to be working with distributions because they are going to-do what every they like anyhow and are not going to provide gnome developers with decent feedback or feature request or bug reports.

billyswong gnome actions out of context seams like gnome is being a jack ass for no reason. I would say gnome is totally justified from distributions interactions with gnome to go forwards not caring what distributions need because distributions have not been properly engaging.

The theming problem has been kicking around since the year 2000 and possible before. I know this because it was one of the early issues I raised on the freedesktop mailing list that I said need to be fixed. At the time I could get zero agreement how to fix it. Horrible I wrote back then that what might be required to fix it is if someone just be a total jackass and forced the issue so ruining everyone work around options so forced to fix the core problem.

[billyswong]

oiaohm I am not against libadwaita itself as provider of higher level abstraction in GUI creation. I listened a bit of that podcast and they mentioned various stuff... I checked it out and see Elementary OS is enforcing a MacOS style to GUI. No I don't like Mac interface so if libadwaita choosing to bypass GTK stylesheets is due to or inspired by they-did-that-first, then it is one jackass encouraging another jackass in my feeling.

[oiaohm]

oiaohm I am not against libadwaita itself as provider of higher level abstraction in GUI creation. I listened a bit of that podcast and they mentioned various stuff... I checked it out and see Elementary OS is enforcing a MacOS style to GUI. No I don't like Mac interface so if libadwaita choosing to bypass GTK stylesheets is due to or inspired by they-did-that-first, then it is one jackass encouraging another jackass in my feeling.

Its multi jackass things. Distributions modify core styles because they had extended theming engine. this results in upstream gnome getting headaches. This result in some application developers considering hard setting themes.

That don't theme my application is import. You have application developers getting sick of bug report from end users from distribution made busted themes and their own busted code. Please note distributions have sat on their ass here being a jackass going we can keep on making what ever themes we like without developing tooling to make sure their theming modifications are quality to recude upset developers.

Yes many jackass things have triggered where we are now with gnome. Yes billyswong with that pod cast the party in it had the host of the pod cast raise the application developers issue and they go and straight basically laugh it off. Not say that yes will will have to counter what gnome as done and work out someway that we don't keep on kicking application developers in the bug reporting teeth with issues.

libadwaita locking a style sheet is way more reservable compared to application developers totally giving up and embedded the style sheet in their application completely GTK3 and 4 allows this do remember.

Gnomes actions with libadwaita is a shot across the bow being a warning shot and the distributions and non gnome desktops are being too stupid to see it. Gnome is better to fire this shot and delay application developers from firing the per application shot that will be a even larger nightmare.

The reality here if we don't sort out theming for all parties involved so it functions some what correctly for them. We can totally kiss good bye to the idea of shared theming that is the road we are on.

[yump]

I understand that color perception is complicated and that color blindness can present a problem for highly saturated colors on dark backgrounds, but fixing that doesn't require throwing out user themes as Gnome wants to do.

Any *remotely* reasonable theme, dark or light, will have a low-saturation background color, either very close to #000 or very close to #FFF. If the application is able to query whether the background is "light" or "dark", that suffices. The app can choose one set of highlight colors to use with themes that have a light background, and a different set of highlight colors to use with themes that have a dark background. Just like vim does with set bg=light or set bg=dark. The app developer need only test with one black-on-white theme, and one white-on-black theme.

If a user or a system integrator sets a theme that uses mid-range value and or high-saturation colors, or that claims to be light when it's actually dark or vice-versa, they did something stupid and get to keep both pieces.

If application developers are given free reign, you get non-native looking abominations like this. That is the crowd that libadwaita has fallen in with.

... and on that note, it's been many years since I've used Windows, but I remember it having way more powerful appearance customization than what Gnome wants, presented directly in the GUI. You could change the width of the window borders, or the scroll bar, and I always shrunk the borders to minimum size to save screen real estate. Didn't even have to know CSS.

[oiaohm]

Any *remotely* reasonable theme, dark or light, will have a low-saturation background color, either very close to #000 or very close to #FFF. If the application is able to query whether the background is "light" or "dark", that suffices. The app can choose one set of highlight colors to use with themes that have a light background, and a different set of highlight colors to use with themes that have a dark background. Just like vim does with set bg=light or set bg=dark. The app developer need only test with one black-on-white theme, and one white-on-black theme.

Its not that straight forwards

If a user or a system integrator sets a theme that uses mid-range value and or high-saturation colors, or that claims to be light when it's actually dark or vice-versa, they did something stupid and get to keep both pieces.

Problem is when users and system integrates and distributions do this still end up application developers being incorrectly hit by bug reports for problems that don't really exist. Remember open source project are short of developer time. Losing time sorting out bug reports on visual issues that don't exist cost time from fixing more critical issues.

If application developers are given free reign, you get non-native looking abominations like this. That is the crowd that libadwaita has fallen in with.

https://stopthemingmy.app/

The reality here is application developers do have free reign. At this stage the application developer have not decided to start jumping ship in a major way but they are quickly running out of tolerance. libadwaita is here because if something is not done there is going to be fragmentation on even worse level. Yes GTK vs QT vs... is a lot better than like 200 of the core application going individually theme by hard line code.

The crowd that libadwaita is attempting to make happy if they are not made happy we will have total disaster. Total disaster there will not even be the option to swap libadwaita to force a theme instead people wanting to custom theme will be forced to patch every application individually.

Application developer crowd is very important crowd that can only get so far unhappy part a particular point they will totally ruin everything for their own workload reduction so they can get applications to their end users with the feature their end users want. Yes lot of applications the theme is least important feature.

... and on that note, it's been many years since I've used Windows, but I remember it having way more powerful appearance customization than what Gnome wants, presented directly in the GUI. You could change the width of the window borders, or the scroll bar, and I always shrunk the borders to minimum size to save screen real estate. Didn't even have to know CSS.

Yes I do hope gnome current work does bring more user accessible customisation. CSS as a solution for theming has not be a ideal solution for general users.

The reality here if we don't want the Linux desktop to turn ugly we have to make it time cost effective for application developers to make applications that can be themed and are not going to result in application developers having bugs open because some user used a different theme.

Something to remember gnome is mostly a collective of application developers.

https://blogs.gnome.org/alatiera/2021/09/18/the-truth-they-are-not-telling-you-about-themes/

Something most people are not aware of this is not a new problem. 2019 basically 2 years ago the problem was raised. Yes as noted their Ubuntu and Pop dark themes in CSS caused did some really horrible. Not just change the color element in fact trigger elements of the interface not to appear all. Why is gnome locking to 1 CSS file. CSS is hazard. Yes windows theme options use to seam like a lot. Compared to GTK CSS file windows theme options are nothing they. Windows theme options done wrong cannot cause elements of the interface to disappear. GTK CSS done wrong sections of the applications interface disappears completely. When I say disappears completely its no longer even rendered to be placed on screen.

So a user gets into a dialog and there no OK and Cancel buttons the developer get a bug report over this and it turns out to be a theme error that causing the ok and cancel buttons in the dialog not be rendered so nothing wrong with application. I am serous there have been bugs like this reported on different GTK applications.

A system wide theme file really should not have the ability to Thanos Snap half applications interface out of existence. Scary enough that exactly what gtk CSS has the ability todo and worse. Please note GTK CSS theming on Linux not the only toolkit theming that include the Thanos Snap the interface feature. Yes for all those options you could set in MS Windows theming not one or any combination of could Thanos snap the windows applications interface pieces out of existence(yes could make interface bits hard to use but that very different to Thanos Snap).

What theming can mess up in a application defined interface need to be defined and need to be more restricted than what GTK CSS currently is. Yes working on this change equals disruption when you cannot get distribution theming makers and other parties to turn up for over 2 years to meeting over themes to attempt to write up a requirements list.

[billyswong]

The fastest solution to crazy stupid themes is to add a "compatibility mode / safe mode" switch. Give users a easy way to test run any GTK program in "safe mode" theme in run time (without changing the global theme). Then whenever a stupid visual bug occur, a user can try to rerun the application in safe mode theme first, before filing the bug to application project. If they found problem is not there in safe mode, then they can choose to file the bug to theme project instead. Only visual bug that occur in "safe mode" would be accepted by application developers.

Of course then the next question is, do we allow only one fixed theme to get the safe mode badge? It is nowadays commonly agreed that one shall be able to choose GUI in either light mode or dark mode. But what about people who want bigger text? Before hiDPI interface scaling exist, it is common for users that want bigger font and bigger icons specify their size in GUI theme. And there are also people who like small font and small icons. These are all common accessibility stuff that seems logical to accept and include.

What remaining is, would those fancy distribution short circuit the safe mode in their fancy customized graphic interface too? Nothing can stop them stepping others' foot....

[billyswong]

The trouble of "CSS is too powerful" stems from CSS isn't purely decorative. It is also handling layout. Yeah, all those "responsive design". If we want to allow global desktop environment theme to handle layout "density", then we can't ditch all layout handling feature of CSS even if we design a more restrictive replacement of CSS for GTK. Now it is a difficult question: Who get to decide GUI density of applications? User theme, GTK / Gnome, or let applications hardcode them all? (Yes, I understand applications can always hardcode them all, just like applications can always ignore theme colour and paint things in their own way, which is usually what fullscreen games do.)

[oiaohm]

The fastest solution to crazy stupid themes is to add a "compatibility mode / safe mode" switch. Give users a easy way to test run any GTK program in "safe mode" theme in run time (without changing the global theme). Then whenever a stupid visual bug occur, a user can try to rerun the application in safe mode theme first, before filing the bug to application project. If they found problem is not there in safe mode, then they can choose to file the bug to theme project instead. Only visual bug that occur in "safe mode" would be accepted by application developers.

Of course then the next question is, do we allow only one fixed theme to get the safe mode badge? It is nowadays commonly agreed that one shall be able to choose GUI in either light mode or dark mode. But what about people who want bigger text? Before hiDPI interface scaling exist, it is common for users that want bigger font and bigger icons specify their size in GUI theme. And there are also people who like small font and small icons. These are all common accessibility stuff that seems logical to accept and include.

What remaining is, would those fancy distribution short circuit the safe mode in their fancy customized graphic interface too? Nothing can stop them stepping others' foot....

This is why back in 2019 lead gnome developers was attempting to get distribution vendors and other parties involved with the problem. Yes everything you just list was in the 2019 presentation as what need to be talked about and be resolved.

The trouble of "CSS is too powerful" stems from CSS isn't purely decorative. It is also handling layout. Yeah, all those "responsive design". If we want to allow global desktop environment theme to handle layout "density", then we can't ditch all layout handling feature of CSS even if we design a more restrictive replacement of CSS for GTK. Now it is a difficult question: Who get to decide GUI density of applications? User theme, GTK / Gnome, or let applications hardcode them all? (Yes, I understand applications can always hardcode them all, just like applications can always ignore theme colour and paint things in their own way, which is usually what fullscreen games do.)

If we want to avoid more application developers hard coding the lot because dealing with platform theming is too annoying a solution has to be found.

Yes again this is a very difficult problem. System76 with pop Os and others need to wake up. They need to be taking part in gnome gitlab they need to be taking part in the meetings over theming. The downstream we will just patch it so it will do what we want must end. This downstream patching is painful to application developers and end users due to creating unpredictable issues.

Yes if you listern to that podcast again. You will hear those distribution people saying leave us with CSS totally ingoring is horrible issue of being layout destroying so interface destroying so harming application developers and end users.

There is freedom and then there is disasters.

Gnome developers are waking up we are running out of time. This is why they are so willing to just push right down that application using X library will not be working with those who have failed to take part with upstream. This is purely meant as a warning of what is coming. If the theme program is not fixed it may fracture in ways that will never be fixable. Yes if every application locks their own theme pop OS and other distributions like it don't have enough developers/maintainers to be reversing the alteration.

The old saying don't shoot the messenger. In this case gnome is the messenger and they are attempting to shot the messenger without understanding the message. The message is a big scary one.

[billyswong]

Okay I continue listening the podcast. They said even Fedora need to add downstream patch / extension / binary stuff just for the sake of having their own distro logo in the interface. Since Fedora is owned by Red Hat and Red Hat is a major sponsor of Gnome, this doesn't make sense if Gnome maintainers are open minded to accept downstream merge request or feature request. Gnome team, since Gnome 3, got a bad reputation of not listening to outsiders and insisting on doing things in their own way. The situation of Fedora looks like a good evidence of that. Can we really be sure those "who have failed to take part with upstream" are not actually upstream's fault?

[oiaohm]

Okay I continue listening the podcast. They said even Fedora need to add downstream patch / extension / binary stuff just for the sake of having their own distro logo in the interface. Since Fedora is owned by Red Hat and Red Hat is a major sponsor of Gnome, this doesn't make sense if Gnome maintainers are open minded to accept downstream merge request or feature request. Gnome team, since Gnome 3, got a bad reputation of not listening to outsiders and insisting on doing things in their own way. The situation of Fedora looks like a good evidence of that. Can we really be sure those "who have failed to take part with upstream" are not actually upstream's fault?

Yes we can and fedora maintainers are just as gulity non engagement since 2018..

https://foundation.gnome.org/2018/05/31/gnome-moves-to-gitlab-2/

In 2018 gnome moved from bugzilla to gitlab. Before this change a few bugs where opened for distribution theming. Since 2018 there as not been a single distribution theming feature request bug opened and not one of the distribution theming feature request bugs open prior to 2018 answered gnome traige people that they wanted the bug migrated from bugzilla to gitlab.

The fedora maintainer did get very fed up with the distribution logo patch and it not going up stream and the bug ceased being maintained. Yes that old prior 2018 bug fall though because the only partly supporting the upstream bug was the fedora maintainer. Please note the RHEL distribution itself does not use the distro logo interface that is in fedora. RHEL and Fedora maintainers are not the same people for core design. Yes this did not bode well for the Fedora logo patch when the Fedora appearance maitnainer and the RHEL appearance maintainer were not agree with each other.

https://wiki.gnome.org/Design/OS/DownstreamBranding

https://bugzilla.gnome.org/show_bug.cgi?id=695691

Yes this bug here is not migrated to the new gitlab its been 2 years. But this bug is blocked.

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1399

Michael Catanzaro @mcatanzaro · 3 months ago

Fedora (they patch Settings 🙁)

FWIW the distro logo is our only patch! I'd love to be able to remove it now that !985 (merged) has landed, but it requires some downstream work in Fedora, CentOS, and RHEL to ensure it looks good. (The Fedora package source is upstream for all three.)

This is in the current work in distribution branding. That right a different logo branding system to what used in Fedora has merged upstream. This has been what the distributions like arch, endless... working upstream wanted. Fedora/CentOS/RHEL lost the vote. Please note system76 pop did not even vote.

You want to show you distribution logo in the gnome control panel right. Gnome allows you to-do that. Only one problem look above the distributions are not providing all the same size logo. So here they are screwing up the window formatting. This is before they even attempt to make their own themes.

bad reputation of not listening to outsiders

This should not be seen as bad reputation at all. Gnome is seen altering itself to support what arch, endless and quite a few other distributions want in distribution theming.

Gnome does not listen to parties that are not engaging with upstream. Gnome might be quite slow to get though the diplomatic process as in the distribution logo bit. And by the diplomatic process your idea might be rejected and a different one taken on by core.

The distributions complaining about what is being done to gnome theming have not been taking part in the upstream work. Yes locking to one CSS theme as a temporary solution is something all the upstream gnome engaged Linux distributions agreed todo.

The reality here gnome in the past 2 years has not seen new distribution maintainers join the ranks on distribution branding to have their input. Yes this is to have input on important things like theming engine changes. Complaining on a podcast is one thing.

Yes remember you have these third party distributions picking up the fedora logo patches today without being aware upstream as merged something else so making those patches deprecated.

Stable interface for end users will require distributions to agree on methods they are going to use to theme/brand things so that in the process of theming and branding they don't bring the house down on end users.

KDE and other DE/wayland compositors also need to start having the same debate with distributions over branding and theming.

System76 Pop OS maintainers when comes to branding do have a bad issue of not working with upstream. Them moving to EFL will not fix this problem. You need the distributions using a toolkit at least to atleast have common area to debate how they will theme it not to break the house on people. Yes that common area makes sense as upstream.

Gnome policy anyone can come a insider by being involved. Yes there are people from debian, arch, endless, fedora who have voting rights over distribution branding features on gnome these are also involved upstream and are submitting patches and fixes upstream. Yes pop os has a lot of patches they are applying to gnome that have not been peer reviewed this is not good for end users either.

Sorry I have zero tolerance for the distributions complaining about the CSS locking at this stage as they have close to zero upstream gnome engagement.

KDE personal some of them do have voting rights on theming and distribution brand stuff in gnome they did loss vote over CSS locking so at least they had engagement and maybe over time a different solution to their issues will be made.

Gnome upstream did not take the choice of locking the CSS lightly. Upset distributions that one problem. Application developers getting that pissed that they decide to lock their theming themselves that is a way worse problem. By gnome locking the theming CSS this prevented per application fragmentation yes they knew it was going to put some distributions and DE/wayland compositor noses out of joint. Yes gnome developers also knew once it was locked CSS they would be able to increase the feature set over time and hopefully make the distribution and DE/wayland compositor back happy again.

That don't theme my application from application developers is a very serous problem. Lot more serous problem than a distribution complaining I cannot custom theme my distribution. Losing a few distributions from having gnome is better than having hundreds of application developers using GTK deciding to absolutely lock there theme individually.

Once application developers burn the system theming to the ground rebuilding it is going to be very hard. Burning a bridge to distributions is a lot more repairable problem. Yes the CSS theme locking is a response to a very serous problem. Themes cannot keep on breaking application interfaces and application developers are running out of tolerance for it and the methods open to application developers alone to fix this problem is good for no body. So we need a theming solution that applicaiton developers can be happy with as it does not break their programs as problem 1. Problem 2 is how to make solution application developers happy with provide the branding and unified teeming to non gnome stuff.