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

[Mez']

though I dont know how it compares to EFL) and GTK is no longer beholden to any specific platform. Precisely everything you wanted.

Read the link above I gave, Solus and Budgie are experimenting with it and will replace GTK with EFL. There are a few technical comparisons regarding both.

It should be green grass and unicorns for everyone.

Most distro maintainers seem to entirely disagree with that assumption.

[Mez']

Gnome devs are taking a stance for the direction they want to lead Gnome to, with libadwaita and it's wrong on almost every way regarding what brought all of us to Linux in the first place (theming and the ability to tinker in your system and customize it to your needs). They are attempting step by step to close Gnome down for anyone who wants to theme it, add extension etc... and their close-minded vision of "if you don't like it contribute, oh thanks for the suggestion but we don't want that" is starting to make people really angry.

Joshua Strobl of Solus and Budgie DE has written a long blog post in which he explains why Budgie will no longer use Gnome bits in the future as the direction it's taking is a huge issue for developers and users. It's a very interesting read and it totally converges with what I've been saying all along. I'm very happy Budgie will distance itself from Gnome in the future and it has a bright future thanks to that, while Gnome will see people move away due to not listening to anyone but themselves, and being a bigger obstacle every new release to user-friendliness.
https://joshuastrobl.com/2021/09/14/...ive-ecosystem/

A few extracts:

"What used to be a community welcoming diverse ideas, focused on providing an equitable ecosystem for many members of the Linux community, has gradually turned into an isolated silo of thought that pays little mind to the concerns raised by its users."

"On social media, it has not been any better, with some GNOME developers dismissing concerns by just claiming that nobody from System76 ever engaged with GNOME on the matter, which is materially false, and made remarks that these developers “instead prefer to rant on twitter”."

"While I certainly recognize that the opinions, words, or actions of some of these developers may not reflect the entirely of GNOME, the regularity of this behavior from GNOME contributors clearly speaks to a cultural problem inside of GNOME. They aren’t just being anti-user at this point (actively making it more difficult to curate their own Linux experience), but anti-developer as well. Rather than listening to the concerns of entire operating systems and many of their own users on the negative impact of GNOME’s decisions, they have doubled down. This sort of behavior is destructive to the work so many of us, GNOME developers included, have done to try to ensure Linux is a viable desktop computing platform. It alienates folks and further perpetuates the view in the Linux community that GNOME does not listen and is hard to work with."

"If you are a desktop Linux user and want to have a consistent experience across all your apps, good luck with that once GNOME apps start adopting libadwaita and GTK5 becomes a thing. If you are building a desktop Linux application at this point and you want to provide flexibility for your users or allow operating systems to ship your app, with users being happy with how well it integrates with the rest of their Linux experience, using GTK4 and beyond is going to be shooting yourself in the foot."

"Given the current state of GTK4, the possible future of GTK5, and the likely fragmentation in user experience that is to come, the obvious question is: Do we still build Budgie and Solus software with GTK4 and beyond?

It would not be in the best interest for Solus to invest in a future version of Budgie that leverages relevant software (GTK as an example) developed by GNOME. In fact, it would not be in the best interest for Solus to invest at all in developing any software leveraging GTK4 and beyond. It would put us in an undesired position of being progressively negatively impacted by conscious decisions by GNOME, not to mention implying to others that we support the direction GNOME is taking their software stack, when that reality couldn’t be further from the truth."

"For the Solus GNOME Edition, I am no longer confident that I can continue to provide the necessary curated experience that many of our users expect from a Solus edition. In lieu of dropping the edition entirely, alienating people that want to use Solus while also happening to prefer GNOME Shell, we will cease shipping a curated GNOME Edition in the next Solus release, giving it a clear “non-curated” designation and demoting it to a separate section of our Downloads page."

[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.

[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]

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]

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.)

[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....

[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.

[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]

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.