Is GNOME Actually Evil?

The earliest of the sources sent to me by my 'friend' is a ticket on the Transmission application from 2010. In it, a GNOME developer offers the author of Transmission a heads up that GNOME 3 isn't planning to support notification area icons, and says that since the option to do that will therefore no longer be cross platform, it should probably be removed. This is probably a bad idea, to be fair, but I don't think leading with that suggestion is really all that heinous, since the idea of a cross-platform app is to support the common denominator features between the platforms, at least if you don't want to add flags to adapt. After pointing out this is probably a bad idea, the author of Transmission says:

In order for this ticket to move forward, I'd like you to tell me what change should be made to Transmission that will make it work properly, out of the box, on GNOME Shell, Unity, and XFCE.

Obviously, at the time he wrote that, that just isn't possible. The entire point is that they've all got different features, so unless you want to have three separate versions, or remove the feature, you'd have to only support one way of doing it and not have the feature on the others. Seeing this, the GNOME developer points that out:

I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.

It is my hope that you are a GNOME app. Yes this kind of fragmentation is unfortunate. I'm not happy about it either. Anyway, I just wanted to give you a heads up. Wish you the best.

I think this is a totally fine and fair thing to say. It's true that they can't/wont' support all three, and so the GNOME developer points that out, admits it is unfortunate and that they aren't happy about it either and that it isn't ideal, and humbly says they like the app and hope it'll be on GNOME. They also confirm what was clear from above, that this wasn't a demand or even a request, nor a really thought the GNOME developer was just trying to be helpful, letting the Transmission developer know what the problem was, and trying to offer a simple solution along with the heads up, as is good etiquette for issues. The fact that they didn't offer a more involved solution isn't really on them, or a sign of malice, in my opinion.

Does Charles react normally to this? No. He reacts by melodramatically performing his shock, his shock, that the GNOME developer had the gall to say he'd have to choose, as if they had any control over that. The GNOME developer offers his sympathies again, but points that out. A month passes, and then the same GNOME developer and another one show up to offer a more fully realized solution this time, seeing how at a loss Charles was.

mccan:

The solution for GNOME 3 and the GNOME 2 fallback is the same: use a notification when the notification daemon supports persistence. Both the GNOME 3 and 2 fallback notification servers support persistence. So, the guidance from GNOME is consistent here and you shouldn't need to support two separate code paths. As for Ubuntu, I can't say. If you don't want to maintain an Ubuntu specific implementation they would probably maintain the patch in their packages for you.

hadess:

Jordan asked me to make a comment here.

2 things need doing:

• Add a tiny bit of code to gtk/notify.c to check whether the notification server has the "persistence" cap (just like is done for the "actions" cap in can_{supportactions}()), and export it in notify.h
• If gtr_{notifyhaspersistence}() returns TRUE, hide the preference for showing status icons, and just never show a status icon.

This should be enough to make transmission behave well with gnome-shell, and the GNOME 3 fallback. notify-osd doesn't support persistence. The only problematic one would be Mint if they had a newer notification-daemon, which they shouldn't if they're sticking with GNOME 2.

In response to the very idea of being required to support a GNOME-only feature, someone on the forums accuses GNOME of being "diseased":

Rant: I don't know the exact kind of disease someone's spreading in GNOME project since GNOME2 concept days but the feature of dropping every feature someone else might find useful is what should bury that clone project in the long term, and the less people are involved the better.

And morally grandstands about how great they are in comparison, because their products don't have a vision to them, they just do whatever users ask:

PS: my free software is about actually helping myself and others, not about forcing my stupid "brilliant" views onto each other's head and down their throats. It's also about educating people, not about helping those trying to dumb us down and look smart. It's about UNIX simplicity and elegance, not about mind-boggling chunks of ​MSDN camp type code.

So far, this seems frustrating, but isn't diversity of desktop environments, each having differing philosophies and ways of handling things, something the GNOME haters want? If so, this is the sort of world they'll inevitably have to deal with. I don't think calling DE developers evil every time their DE isn't perfectly feature-compatible with another is productive, and I don't think the GNOME team acted in a particularly negative way here. Yes, I can imagine it's deeply unfortunate and frustrating for Charles, who has all these added things to worry about, and I can see why he'd be frustrated with GNOME, but fundamentally I don't think that should mean application developers get to dictate to DEs what features they have.

The second source linked is a post called "GNOME (et al): Rotting in Threes," from the blog of someone going by the tag "IgnorantGuru" (username checks out).

Some of the things you're about to read should make your hair curl and your blood boil.

Off to a good start: telling the reader how to feel, instead of how you feel.

Theme development is a tedious and difficult task, and for the GTK devs to be so careless in breaking their API at every turn disrespects the many hours people put into making themes for it. Yet as I read some of the GNOME developer comments below, I was given to believe that this breakage stems from a Microsoft-like climate of preventing users from customizing their systems…

Wanting to create an open source project that focuses on delivering a consistent vision and user experience, and so doesn't have enough "customizability" for some people, is "Microsoft like" now? I wonder what this person thinks of the suckless people. Surely he'd condemn them too, right? Or is this only a standard foisted upon the GNOME project?

Additionally, yes, developing something that is explicitly not supported, using an explicitly internal API, is going to be tedious and difficult, but that doesn't mean that every single open source project should be forced to slavishly ensure the backwards compatibility of every internal API someone (or even many someones) happen to want to use. That's absurd. If you have any API at all, someone will try to use it, but the amount of work they put into that doesn't give them a claim on the work of anyone else, or on upstream projects, and it's just so absurd for them to complain melodramatically about how hard it is to use internal APIs to do unsupported things with software because they break so often. You should have been aware of that going into it!

…and deliberately breaking the work of others so that your 'brand' is the best.

Ah, so that's where the person on Hacker News got this claim. I wonder whether they are this IgnorantGuru person, or if they've just been duped by him? In any case, just because other people built something on top of your project, which explicitly was not designed for other people to build that kind of thing on top of, that doesn't mean that when you working on your own project happens to break the things other people built on top of it, because you want your project to be the best it can be, that you're deliberately sabatoging other people's work. That's absolutely ludicrous.

Can anyone now run up and start building things on top of your open source project, without you asking them to, and directly flying in the face of the stated purposes and goals of your project, and then point the finger at you and scream like a banshee in protest about how they've been sabotaged, sabotaged I tell you! because the thing they should've expected to happen, gone in knowing would happen from the very start, that the person who makes a project continued developing their project according to their own freedom, had happened? Does just randomly showing up out of the blue and piggybacking on someone else's work now give you the right to demand more work from them? Does it give you the right to set the goals for the projects other people give their labor freely to, to direct others' free labor?

That seems to be the logic here.

Anytime I hear the word 'brand' being used in Linux, I know something valuable is being poisoned.

latching onto a corporate-sounding word as evidence of the person using it being the root of all evil, when in reality, if you're trying to make something for people who aren't necessarily enthusiasts who will research everything to death, marketing and brands are an inevitable part of that: you need to find some way to communicate who you are and what you're about to people if they're going to find out about you, after all. This isn't even mutually exclusive with believing in your project and wanting the best for users, it doesn't have to be driven by any sort of profit motive, nor does it have to be at the cost of anyone else.

Yet what I'm hearing is that with GNOME v3 the goal is to promote their "brand" and make it dominant, in part by greatly limiting what users can change on their own systems, and partly by breaking or simply removing whatever support they're no longer promoting as 'The Way'. The reach of this selfish and narrow-sighted development goes beyond GNOME and affects GTK apps in general.

As I said before, wanting more people to use your open source project is fine, as is having a "brand." This is just bad faith. Likewise, as I've also said before, having a precise, specific, directed vision for your project, and culling anything that is out of scope or conflicts with that vision, even if that vision is minimalism, isn't something evil. It's not "selfish" or "narrow-minded," because they're not forcing anyone to use their project.

I genuinely understand that might be really inconvenient and frustrating for many users, and that's genuinely unfortunate, and I don't agree with many of the specific decisions GNOME made, especially prior to the 40 series, but the amount of hyperbolic crying about this is absolutely insane. There was a fork of GNOME 2, why not have everyone who doesn't like nuGNOME switch to that en masse, both as users and contributors, and really show GNOME what for? GNOME really doesn't have that many more people or resources than any other DE, it's not like no one can hope to match them or anything.

Stop trying to enforce your vision on a project when that simply isn't what the project is, and go use something else.

That's the entire point of open source: letting everyone scratch their own itch, trying to build the best version of the thing they want that they can, and if you disagree, you have the ability to take someone the ability to walk out, and take everything you need to get started with an alternative with you (the full source code and documentation).

Would it really be fair of a vocal contingent of people to, for instance, show up at the door of Void Linux, or Alpine, or the suckless people, demanding that they add incompatible features or fundamentally change how they do things, just to suit them? I think if that happened if, for instance, GNOME users flocked to KDE and started demanding you would be able to clearly identify the problem, but yet, somehow, when it comes to GNOME, the same logic doesn't apply?

Windows devs seem to be arriving as well, bringing their diseases with them – corporate 'kill off the competition' mentalities that don't serve Linux, merely exploit it.

really great of you. I wonder if IgnorantGuru is the same person as the one that accused GNOME devs of being from Microsoft and being diseased in the previous article. Almost certainly not, to be fair, but it is interesting how often these thought-patterns repeat. You'll see more of them, too!

The rest of this continues in a similar fashion: quote after quote this blog author is completely outraged and shocked that the GNOME team has a consistent vision for their project, instead of wanting to acquiesce to the demands of the mob, and cares about a consistent experience for users and "branding" and "marketing." See for yourself:

#+begin_quote GTK3 isn't a reliable API. Maybe it should be called libgnome instead. GTK3.4 came with Gnome3.4, and wasn't compatible with previous GTK3 themes. This means all GTK3 applications looked really ugly not only with all the GTK2 themes which don't support GTK3 (almost all of them), but also the few which did.

#+end_quote

Not being a reliable API, and not being a reliable API for theming, an explicitly unsupported functionality achieved using internal APIs are entirely different things, but here whoever wrote this quote is equivocating between them to make GTK 3 seem much worse than it is. This is a pattern we will see often.

#+begin_quote I'm no longer interested in zenity because with Gnome 3 updates, it lost some features, and I had scripts not working as they should. I didn't understand why. Even the zenity docs were not updated about removed features. I had to search in bug reports to find that developers removed some features that were no longer considered useful with the new Gnome Shell paradigms. Wow. So devs think that zenity is Gnome Shell only? It can't be used in other environments? I was very frustrated. … there's clearly an adoption of a very closed-source way of functioning, more and more disconnected from users and obsessed with brand control.

#+end_quote

Zenity is explicitly a GNOME-only project. Not only is it*hosted on GNOME's version control system*, something I doubt was different in 2012, wherever they hosted their stuff back then, because project self hosting of source was even more common back then, they even say: "This is Zenity: the GNOME port of the venerable 'dialog' program, which allows you to display dialog boxes from the command-line and shell scripts." It is the GNOME port of an existing tool. So yes, of course it is GNOME only. Of course they don't feel the need to notify users about a change ot an internal tool.

#+begin_quote it's such a pain to develop a GTK 3 theme. It's always broken. I have a version of my theme for GTK 3.2, one for GTK 3.4, one for GTK 3.6. I'm so tired of that. For GTK 3.4, it was so broken that I had to code it again from the beginning. Days and days of wasted time and frustration.

#+end_quote

I get that sucks, I've tried to make DE themes before and it is a shitton of work, and I really respect the dedication involved in trying to make a theme for others as a result, but this really isn't something you can blame GNOME for. They tell people up front constantly that this isn't a stable API or intended functionality, so complaining when the API isn't stable and the functionality isn't intended and so it causes you to have to do a lot of work feels like shooting yourself in the foot with buckshot and then complaining there are holes in your foot.

#+begin_quote I'm sorry to say this but I am abandoning any GTK3 theme making from now on. Upstream is impossible to work with and GNOME 3 has become a complete mess in regard to third party theme making. … Honestly, Windows and OS X actually look more attractive to me right now.

#+end_quote

This seems like an incredibly hyperbolic statement probably made by someone who's burned out after pushing themselves too hard. I have a lot of sympathy, but this doesn't really constitute good evidence either.

#+begin_quote The problem therein is why should we as supporters of Gnome who gave our time for free get slapped in the face with new theme requirements and our work broken and failing to do more work at out own time to support something where the requirements could change again in another 6 months or less and again break our new work? It's a real pickle no doubts there!

#+end_quote

GNOME never asked someone to theme their stuff, nor does it help them, in fact it only leads to more spurious bug reports and complaints for them, and is something they have asked people to stop doing and don't think is a good idea, so theming work isn't "supporting GNOME." This attempt to make it seem like you're giving to GNOME out of the goodness of your hearts and are getting slapped in return is misguided. You're giving out of the goodness of your heart to your theme users at best, and you should've known up front what using an internal unstable API involves.

How can anyone remain interested in a system developed by devs who don't care about their users? Do you know what GNOME devs think about themes and extensions?

Does GNOME not care about their users, or just "not care" about the users that want something fundamentally different from their DE than what they're even trying to provide?

Below are some tasty answers from Gnome Shell devs, considering users only as walking billboards

#+begin_quote Facilitating the unrestricted use of extensions and themes by end users seems contrary to the central tenets of the GNOME 3 design. We've fought long and hard to give GNOME 3 a consistent visual appearance, to make it synonymous with a single user experience and to ensure that that experience is of a consistently high quality. A general purpose extensions and themes distribution system seems to threaten much of that.

#+end_quote

How dare a project try to have a consistent stable visual appearance and user experience so people can orient themselves and so they can provide quality assurance and proper UI/UX design, and ensure users don't get deluged in distro crap like Android users are deluged by OEM crap?

#+begin_quote One particular issue is the ability for users to modify the top bar via extensions. This part of the UI is vital for giving GNOME 3 a distinctive visual appearance. If we do have extensions, I would very much like to see the top bar made out of bounds for extension writers, therefore. We have to have at least something that remains consistent.

#+end_quote

This sounds like a marketing thing, but I think there's a real point to if nothing can remain consistent, users are likely to get lost far more easily.

#+begin_quote Firefox has indeed profited from extensions and there are lessons that we can learn from that. GNOME Shell isn't a browser, though. We need to be mindful not to adopt the Firefox model without considering the ways in which our needs might differ. … The point is that it decreases our brand presence. That particular user might understand what it is that they are running, but the person who sees them using their machine or even sees their screenshots on the web will not. The question we have to ask ourselves is: how do we make sure that people recognise a GNOME install when they see one?

#+end_quote

I'll admit I don't really care about "brand presence," but I don't think it is unfair or evil for an open source project to care about their brand. That doesn't make them a for-profit company. This is only evil if you assume GNOME doesn't have the right to want to make an end-user product, and determine what use-cases they do and do not want to support, but must instead act as a meek toolkit for downstream developers to use to construct whatever desktop experience they want. But that simply isn't what GNOME is.

#+begin_quote We've always argued that if it is anything, GNOME is a UX. There might be a case for letting people tweak things here and there, but I really think that every GNOME install should have the same core look and feel. Otherwise, what is it that we are doing in the first place?

#+end_quote

And I think the fact that their core concern is with being able to do to ensure a good clean user experience for their users, shines through here, despite the marketing-speak above. And again, while the lack of configurability in macOS or Windows is really awful, because users are locked into their platforms, GNOME is an open source desktop environment, one of many users can easily choose and switch between all without even reinstalling their operating system, so GNOME rigidly pursuing its vision simply doesn't have the same implications as macOS or Windows doing it.

For example, Gnome Shell doesn't support status icons, so GNOME dev 'mccann' filed a bug report to a Transmission (BitTorrent client) dev to say that this option should be removed. Why should it be removed? Because Gnome Shell doesn't support it anymore! Apparently in GNOMEland there are no other desktop environments (remind anyone of Microsoft?) From Don't use a notification area icon in GNOME 3…

We already covered this one.

More quotes of the quotes the author of this blog thinks are evil:

#+begin_quote I think one of the most important cases against applets (as they are currently defined in GNOME) is that they are extremely detrimental to the Identity of the product or platform. Today, our entire desktop identity is defined by a configurable number of horizontal or vertical bars filled with any number (even duplicates) of random Things that may launch stuff, open menus, open dialogs, operate on windows, switch workspaces, and more! Boxes-o-crap as I lovingly (in the eulogistic sense) refer to them. Each time I see "Remove from panel" when I right click on the notification area or the menu system I weep and my mascara runs and god is it awful.

#+end_quote

I think this illustrates really well the core UX insight at the core of GNOME: visual information overload sucks for a lot of people. Some people like it, but others would prefer an experience that isn't like that out of the box and isn't designed to end up that way.

#+begin_quote Let's say that we are trying to define either a product or a product platform. I don't think it is possible to do this without some "brand" coherence. And it is arguably impossible to do this effectively with such an ad-hoc/individually-customized design identity…

So, one of the many very exciting things about GNOME Shell is that for the first time we may have ability to really shape the user experience and form an identity for the GNOME platform.

#+end_quote

Can't have someone wanting to actually be able to directly shape the user experience of the desktop environment they're spending all this time and energy designing and doing UX testing for, right? That's obviously evil. And god forbid someone wants to have some visual and UX consistency between instances of your platform, and a visual identity so people can identify you and know what you're getting, an integral part of actually making all the different projects in the world legible to the average user so they can choose between them.

What follows is an endless litany of outrage over the various features GNOME removed in the process of paring back and fundamentally almost all of which, I might add,*/have been added back/*, either putting the lie to the claim that GNOME doesn't listen to users, or putting lie to the claim that they didn't mean to eventually bring back those features in a new way. See, they were fundamentally redesigning their UI and UX from the ground up, so of course they would have to remove. You can criticize the project on the grounds that these are bad decisions, but not say they're evil for making them.

The author also quotes some things from GNOME developers saying they view the GNOME "Fallback" mode as a distraction that makes the user experience of their desktop environment worse, because it means you'll end up with a whole island of users camped out on something that was only supposed to be a temporary band-aid for people who couldn't function without a familiar interface, an fallback mode that inherently has no future because that's not the direction GNOME is going in, meaning GNOME would either have to maintain both, or just deal with the consequences of that, and IgnorantGuru interprets this as the GNOME developers seeing fallback mode as "competition" in a business sense that they must extinguish like Microsoft does or something, and files it away as further evidence of their evil:

"the presence of fallback mode is having a negative impact on the quality of the primary GNOME 3 user experience"

See also this report: (fallback) [meta] Remove fallback support code

At some point, the author loses track of the focus, and starts ranting about actually bad behavior on the part of Canonical/Ubuntu: not just not implementing features people want (the horror!) but actually closed sourcing things, collaborating with Amazon, giving away user data, etc. This is all actually bad behavior, but it being here, alongside GNOME's comparatively innocent and completely tame behavior, treated with equal really demonstrates this author's total lack of a sense of proportion. So let's move on.

This one is pretty easy. It's a tabloid-tier article from "IT Wire" about nothing more nor less than Linus Torvalds clapping back against a meagre, milquetoast comment a GNOME developer made on Google+ that he didn't like. It doesn't even really have anything to do with the other complains about GNOME. Lets first read the statement that Torvalds doesn't like:

In my opinion, the problem with Linux on the Desktop is rooted in the developer culture that was created around it.

Linus, despite being a low-level kernel guy, set the tone for our community years ago when he dismissed binary compatibility for device drivers. The kernel people might have some valid reasons for it, and might have forced the industry to play by their rules, but the Desktop people did not have the power that the kernel people did. But we did keep the attitude.

The attitude of our community was one of engineering excellence: we do not want deprecated code in our source trees, we do not want to keep broken designs around, we want pure and beautiful designs and we want to eliminate all traces of bad or poorly implemented ideas from our source code trees.

And we did.

We deprecated APIs, because there was a better way. We removed functionality because "that approach is broken", for degrees of broken from "it is a security hole" all the way to "it does not conform to the new style we are using".

A completely milquetoast take, one that honestly I could go either way agreeing or disagreeing. I think there's something to be said for a culture of engineering excellence, so we don't end up bloated crapware like macOS and Windows, or saddled with bloated crapware of our own like Xorg, but there's also something to be said for the sheer consistency and commitment to backwards compatibility of Windows (although not macOS).

What sin does this commit? Let's hear what Linus has to say:

The gnome people have their problems. They do seem to like to blame pretty much anything but themselves. … The gnome people claiming that I set the 'attitude' that causes them problems is laughable.

Two insults, okay, that's par for the course for Linux, to be fair.

“One of the core kernel rules has always been that we never ever break any external interfaces. That rule has been there since day one, although it's gotten much more explicit only in the last few years. The fact that we break internal interfaces that are not visible to userland is totally irrelevant, and a total red herring.

Funny that he brings up the red herring fallacy, because that's exactly the GNOME developer's whole point is that there wasn't any stable interface for drivers to interoperate with the kernel, just look at how often NVIDIA's proprietary drivers, which have to try to link up to the kernel's internal binary ABI, break.

Now yes, Linus is right that he also has had an impressive long-term the classic "never and so he probably isn't at fault for this tendency in the Linux world to break interfaces, or at the very least that his legacy is more complex and multifaceted than simply him being at fault for that tendency, so I would agree that, overall, this GNOME developer seems a bit ignorant of kernel development, and a bit ungrateful to our lord and savior Linus Torvalds.

In general, the statements from the GNOME developer do seem a bit hypocritical considering how GNOME would later operate, and in general it's just a lukewarm and mildly ignorant take, but one a great many but what, exactly, is this evidence of? That people have bad takes, or can be hypocritical sometimes? I mean, yeah, absolutely. But I imagine Miguel's own views have changed to align with his actions post-GNOME 2, and honestly this doesn't prove to me the whole project is bad or that he's a bad apple or anything.

Linus continues with some unoriginal digs at the GNOME project in return (perhaps fair game given the way Miguel talked about him):

"I wish the gnome people had understood the real rules inside the kernel. Like"you never break external interfaces” - and 'we need to do that to improve things'” is not an excuse.

“Or 'different users have different needs'. The kernel was - and is - happy to support both the SGI style thousand-CPU machines and the embedded vendors with cellphones and routers. The fact that they have different needs is very obvious.

“I personally think that one reason that the Linux kernel has been so successful was the fact that I didn't have a huge vision of where I wanted to force people to go. Sure, I wanted 'unix', and there are some very high-level concepts that go with that (fork,exec,files etc), but I didn't want to enforce any particular world-view outside of that very generic pattern.

…

"That's exactly the reverse of the gnome 'we know better' mentality, and"We will force Corba/.NET down your throat whether you like it or not, and if you complain, you're against progress, and cannot handle the change'…”

"Some gnome people seem to be in total denial about what their problem really is. They'll wildly blame everybody except themselves. This article seems to be a perfect example of that."

I'm not sure what that line is really worth, it's just playing the same and I think it is but the rest is just the usual complaints about GNOME focusing too strictly on pursuing the refinement of the one workflow it's after, and claiming that implementing a feature in their own project that people can easily switch away from if they don't like because unlike Windows or macOS you can easily switch DEs or even entire Linux distributions, there isn't vendor lock-in, is somehow "shoving" things "down user's throats."

Honestly, again, this is just more evidence that people don't like GNOME, but not really evidence there's a solid reason for it, that there's a real problem or actual abuse coming from them. People are occasionally hypocritical and occasionally have slightly bad takes once or twice in a decade. That's fine. It isn't a heinous crime.

This next one is a real doozy. It's IgnorantGuru again, this time opening a general philosophical discussion thread with a clear ax to grind, one likely to lead to flame wars, in GNOME's bug tracker, inviting his friends to join the party, and then acting surprised and upset when a GNOME developer tells him that this isn't the place for his shenanigans.

It begins with this post:

IgnorantGuru: As a general but substantial and well-evidenced issue, I believe your dev team should examine why you are repeatedly and carelessly breaking themes with every minor gtk3 release version

"Examine why?" They know why. You just want them to change their minds about their own goals for their own project, but don't hide it behind obfuscation like this.

This makes it very hard to develop a stable app in gtk3 despite the core api seeming to perform well,

If the core APIs are stable, then it should be very easy to develop a

breaking your app, and other apps, because they haven't caught up with the internal API they're hijacking… also, why the hell is that an application developer's concern anyway? people choose to theme their desktops, yes, but you're not responsible for every single theme someone decides to slap on your application, downstream of you, that isn't part of your application, nor is it part of your mandate. This is just a transparent attempt to conflate applications with the themes that may sometimes be applied to them, so that if a theme breaks it becomes tantamount to the application itself not working (despite it working just fine under the covers, and the theme being the broken thing added on) in order to make this annoying discussion about themes seem more important.

and also wastes the time of theme developers - you can see the frustration they're expressing, and their comments that "upstream is impossible to work with"… http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ Many are simply giving up on gtk3 as a result.

Right, because GNOME has made it clear theming isn't officially supported. So what? Like, yes, it sucks that it's so much work to keep up, but again I don't see how this is anyone's fault but their own, or why that gives them a right to demand the GNOME people act a certain way.

As an app developer, with a new port to gtk3 in testing, I'm already seeing many bug reports caused but this issue alone - theme breakage due to poor maintenance and lack of consistency on your part. What good is an api which breaks so frequently that everything is almost always in a broken state?

Poor maintenance on GNOME's part, and not the themes'? What DARVO shit is this…

Giving you the benefit of the doubt that this isn't being done or ignored deliberately in some effort to support gtk3's use within gnome exclusively (as some are saying), it seems strange that you would put the effort you have into making gtk3 very stable and usable, really excellent work in many regards, and then destroy the usability of that work with careless theme api breakage. The theme is ultimately what the user experiences.

After accusing the GNOME team of wanting to break other people's things in a very Trumpian way (as some are saying, while linking to their own block that says exactly that), they of course finish with a patronizing and moralistic remark:

Remember to step back and examine systemic problems in your dev team, rather than just repeating the same mistakes and looking myopically at issues in isolation.

Of course, rightly, the GNOME developers point out that this isn't actually a bug that's been put on the bug tracker that's for bugs, not discussions:

Emmanuele Bassi: is there an actual bug, in that wall of text, or are you just venting for theme changes?

… bugzilla is not a place for introspection. you are also operating under the impression that there are "lead developers".

if you have specific bugs and regressions, you're strongly encouraged to file them - along with test cases, if possible, so that they can be caught by the test suite.

if you're just venting because the themeing classes, which are not currently under any stability promise, change while we fix bugs then the gtk-devel-list mailing list is a better option for you to be heard by anyone beyond your echo chamber.

To which IgnorantGuru replies, Orwellianly:

This is a very specific bug, it's just broad. You don't seem to be addressing it at all.

I still think an effort to analyze this severe problem is in order, not just wasting time in a long discussion and denials of the problem on the mailing list - I don't have time to correct your development problems, sorry. I'm just reporting the issue to you in the hopes that you would want to address it.

I'm not sure what exactly IgnorantGuru thought would happen differently on a bug tracker than a mailing list, especially since features that aren't intended to ever be implemented aren't bugs, and the GNOME people seem a bit confused too:

we have two wildly differing definitions of "specific", I am afraid. again: if you have specific instances of things that broke between 3.4 and 3.6 (old stable and current stable) we'd like to get bugs detailing them. … if you don't have time to deal with bug reports then I don't feel very much compelled to answer broad questions that are more suited to the development mailing list than to bugzilla.

To which IgnorantGuru grandstands about how mean GNOME is, but does offer the possibility of getting some specific bug reports:

Very well, I have changed this to UN-RESOLVED so you can get some further info from theme developers. I asked some theme developers I know to add some details, but they said they have wasted too much time trying to get you to fix anything, and simply refuse to be "fooled into participating" anymore. That's quite a relationship you have with gtk3 theme devs, many of which I know to be very conscientious and helpful contributors. You must have done some number on them to alienate them all the way you have - nice support work. I guess the fact that people are saying that gtk3 "upstream is impossible to work with" means nothing to you, and doesn't indicate any problems in your dev team.

A bit later, Benjamin Otte helpfully shows up to explain himself candidly about the themes, as IgnorantGuru asked:

Hi, I'm the guy that has spent the last two years breaking themes with every release. This is 100% deliberate and I intend to continue this process for the forseeable future. I've been very open about this and told this to all the people that have asked me about it (read: not you) and done so repeatedly. So it's not a new thing.

But because you asked, again, here are the reasons for why this choice was made:

1. Moving the theming code from its antiquated underpowered gtkrc format to a web-inspired CSS format respecting the CSS box model that can be animated is not a simple task that can be done quickly. And if done slowly, it likely can't be done without breakage.
2. GTK doesn't swim in extra developers that are happy to spend their time ensuring compatibility with rarely used themes. I decided the time was better spent implementing new features than caring about other themes.
3. All the theme authors participating in GTK development (read: not you) agreed that it's better to keep their themes up to date if in exchange they get new features than keeping with the status quo.
4. After those decisions were made, no time was spent on even thinking about compatibility, because there were no people even bringing up the topic, let alone willing to work on it.

And this is why lonely blog posters on blogspot or the mint dev blog (read: you) get all sad and ranty when they don't participate upstream and then decide to only use GTK2 apps.

I'll let you decide who's in the right here: the person grandiosely moralizing, pretentiously and patronizingly telling other people to "examine their systemic problems" for not doing everything they want, hyperbolicly inflating the importance of themes, and claiming "no one said" theming was unstable, or everyone else in this thread.

The discussion branches off from here, debating the specific merits of stability in a theming API in the context of 2012's alpha version of GTK+ 3, and it doesn't seem really that interesting or relevant to the broader discussion here, except to say that it's yet another case of GNOME wanting to do something with their project, and people who built something on top of it (themes) that were explicitly told what they're doing is unsupported because it would simply take far more time investment than it would be worth, and that it was using an unstable internal API, are annoyed GNOME is doing their thing. I think this quote just sums IgnorantGuru's whole deal up, really (from IgnorantGuru himself, in the comments):

Despite your wall of bullshit, the uncensored, unprepared quotes in the article make you quite transparent.

As I just covered above, these quotes don't really show what Guru seems to think they do. He's reading way too far into every little thing to try to justify the worst possible interpretation, but none of the quotes seem to justify his believe that GNOME is trying to act like Microsoft and "embrace, extend, extinguish" the Linux desktop or anything like that. At worst, they show a group of people with a slightly more design and marketing focused mentality than your average Linux developer, which there is space for that in the open source community.

You come from that crowd of elitist corporate developers who would control users, not empower them.

Disempowering users would be taking away their choice of distro or desktop environment in the first place. Offering users a well-designed, curated, focused DE alongside all the other options is not a desire to control people, because people can just pick up and leave. Moreover, the simplified user experience of the GNOME desktop environment could only betray an elitist attitude if they were designing it for others to use, but viewed themselves as too good for it, but that's not the case. If anything, GNOME is designed just as much for the developers that create it as via user experience research, interviews, and surveys.

As an analogy, if you were a doctor, you would be prescribing toxic drugs and using your professional associations to undermine alternative healthcare. If you were a food designer, you would be making processed foods loaded with toxic chemicals and GMOs, and putting your corporate insiders in charge of regulatory agencies. In your elitist 'high priest developer' crowd, the user is just a resource to be exploited at all costs, talked down to, and controlled.

And here we see the general mentality this person has. The logic they are applying here, by their own admission, also leads them to this is it good logic, if by his own admission these beliefs are also analogous?

You may notice, if you read the bug tracker thread, that it seems that the GNOME people know who IgnorantGuru is, and are actively ignoring him. Why are they doing this? Well, besides the fact that he's very obviously doing some semi-polite form of trolling, trying to start moralizing philosophical arguments about vague general issues and talking down to the GNOME developers in a bug tracker instead of the mailing list that's actually for discussions of that nature, it's because he has a long history of becoming obsessively angry at various projects (just scroll through a few years of his blog) and showing up on forums and bug trackers making wild abusive conspiratorial accusations and distorting the facts and then whining about "censorship". In fact, he was still doing this years later, too. Let's actually take a look at that blog post:

I submit the following for your review because it's an interesting case study in how Red Hat developers are running the GTK+ bugtracker, censoring non-flattering input, and misusing their code of conduct. Since they deleted several of my comments, and threatened another participant merely for using the word "overengineered" (lol – if the shoe fits…), I thought it might be valuable to bring what they deleted to larger attention.

claims of "censorship" and "misuse of their code of conduct" seem really bad; if true, these would be serious marks against them. But if we've learned anything about they internet by now, we know that people complaining in a side channel about how they got "censored" on another internet platform for innocent behavior are often not innocent, and often not summarizing what they did correctly. Guru is claiming this partially on behalf of another person, but I think the principle still applies, so to find out what really happened, we'll have to read the bug tracker transcript itself, and come to our own conclusions. But first, let's look at how he summarizes the initial interaction:

The case in study is a bug report regarding the way the GTK+ file chooser (file browser) only shows FUSE mounts made by gvfs, and is blind to those made by almost all other file managers. This is a simple bug. All that needs to be done to fix it is add the traditional location used for fuse mounts to the heuristics – a 5 minute job. Yet instead of simply fixing it, first a Red Hat employee immediately closes it as "RESOLVED WONTFIX" with a "No."

What actually happened, though?

Description Psy[H[] 2015-05-31 19:30:12 UTC $HOME/.cache is a logical place for applications to place user-level mountpoints such as FUSE filesystems. Those should be visible in GtkFIleChooser. Right now it seems to exclude all hidden dirs in $HOME from mountpoint search. $HOME/.cache should be whitelisted.

Comment 1 Matthias Clasen 2015-06-01 16:06:23 UTC

No. XDG_CACHEDIR has defined semantics that don't match mounting things.

[ Marked RESOLVED WONTFIX ]

Alright, so already it's clear he's lying. This is no simple bug, but a difference in design philosophy, and the "bug" is closed as a direct result of that, because the GTK developers want to adhere to the defined FreeDesktop semantics of things, and this person wants an exception added for convenience. Let's see how things continue:

Comment 2 IgnorantGuru 2015-06-02 15:18:22 UTC

I realize that GTK development is effectively dead for non-Gnome projects, but you may wish to consider that several widely used XFCE and LXDE file managers which use GTK, such as Thunar and PCManFM, as well as other programs, do mount fuse and network filesystems in XDG_CACHEDIR, and have done so for years. This is common usage, and not every GTK project follows Freedesktop specs to the letter … Otherwise it is blind to them and fairly useless outside of Gnome. … Just quoting the specs and ignoring common usage to avoid updating it just makes the file chooser irrelevant for real uses. Is GTK now documented as a Freedesktop/Gnome-only project? You have several non-Gnome file managers using GTK, so perhaps supporting their uses as well as Gnome would be appropriate.

Here we find IgnorantGuru showing up out of the blue on a bug tracker for a project he hates, to sling insults and conspiracy theories (adhering to a well-documented cross platform specification for how things work is not being "GNOME-specific", and adding exceptions just to accommodate common usage could actually cause more bugs and issues in the long run) peppered throughout his requests for change. Maybe his requests would have been considered, had he made them in a reasonable manner, even if they'd be a bad technical decision contrary to how GTK wants to work, but obviously he's never going to get anywhere acting like this. A few key points are raised in response to him, though:

Comment 3 Matthias Clasen 2015-06-02 15:41:20 UTC

#+begin_quote Right now it seems to exclude all hidden dirs in $HOME from mountpoint search. $HOME/.cache should be whitelisted.

The file chooser does not do any mountpoint search at all. We rely on gvfs to provide this information.

GTK development is effectively dead for non-Gnome projects

GTK development for non-gnome projects depends on developers from those projects participating and making their needs heard.

The file chooser as it stands apparently ignores all hidden directories, which > doesn't leave good options.

That is not true.

#+end_quote

They aren't even asking for functionality in the right place! Let's read further. Psy and Guru both insist that GtkFileChooser is able to find mountpoints on their system without GVFS, to which Emmanuele explains:

If no GVFS is present, the fallback code will list the Unix mounts coming from /proc/mounts or /etc/mtab; each mount point will be checked via g_{unixmountguessshoulddisplay}(), which will return TRUE for user-accessible mount points under /media, /run/media/$USER, or directly under $HOME.

If you want your mount points to be visible in the GTK file chooser and you don't have GVFS running, you should mount them under "/run/media/$USER".

So there is a fallback for when GVFS is absent, but it expects them to be listed in a different way. Emmanuele does admit there's a bit of a bug there, however, although it would have to be fixed somewhere else, not on this tracker, so this thread should already be closed in my opinion:

The bug in GIO is that the code doing the check hardcodes /run instead of using XDG_RUNTIMEDIR. If XDG_RUNTIMEDIR is unset, it should fallback to XDG_CACHEDIR (which is what g_{getuserruntimedir}() does), but that would mean that the FUSE mount points would go under XDG_CACHEDIR/media/$USER, which is a bit ridiculous.

They go back and forth about what the XDG standards actually say and whether to make GTK conform to them, or to comman usage, a discussion of technical details with IgnorantGuru showing no signs of being censored and the discussion showing no signs of being stopped, only an ongoing philosophical disagreement about how things should work. There is a fundamental problem this entire thread is built on top of, though: this if they were, everything would be standards-compliant and work just fine:

Comment 19 Emmanuele Bassi (:ebassi) 2015-06-02 21:45:36 UTC … To be absolutely blunt, not installing components and then complaining that things are broken is not really cool. It's not like we want to duplicate the logic everywhere: we put it inside some component for a reason. GIO depends on GVFS on Linux, and GVFS depends on udisks. If you're using some other OS, the chain of dependencies is different, but we kind of treat the stack as a stack, not as a pick and mix bowl of "may be nice to have". The reason the dependency is "soft" (i.e. we don't make GIO depend some libraries) is mostly a case of 1. historical accidents; 2. a convenience for integrators to avoid dependency cycles; and 3. because on Windows,*BSD, or MacOS, the dependencies are fairly different.

they're asking the GTK developers to duplicate virtual filesystem handling logic from the software they wrote to handle userspace virtual filesystems into their general library (GIO) just so that people don't have to install things that are listed as dependencies (just not hard dependencies because things do still generally work without them). And the objection might be that gvfs is GNOME-specific, so it shouldn't have to be installed… but so is GIO, and they have that installed. And GTK does work without it, if they adhere to the open specifications for free software desktops!

the comments that got deleted.

The meat of the first comment that got deleted is, as far as I can tell as someone who isn't extremely deeply into GTK development, just a word-salad of nonsensical moon logic:

Actually, you're being absolutely inaccurate. gio does not depend on gvfs – it is part of glib and runs fine without gvfs. Perhaps you should review what a dependency is. From your own docs: "One of the big advantages of putting the VFS in the GLib layer is that GTK+ can DIRECTLY use it, e.g. in the filechooser." https://developer.gnome.org/gio/stable/ch01.html

Iow, GTK+ does NOT depend on gvfs for a reason. The point of putting it in the glib layer was to avoid GTK+ dependencies on DE-specific filesystem abstraction layers like gvfs.

So, to be clear here: the quote from the documentation says that GVFS is part of glib, and the whole point of that was so that GTK+ could but he's claiming that GTK+ does not depend on GVFS at all.

This is but a premonition of things to come however, because he finishes out this comment with this needlessly antagonistic and conspiratorial

statement:

I really [sic – realize] Red Hat has done everything in their power to break that separation and create a monolithic stack, but for now glib is not gvfs dependent.

Then he immediately jumps in to grandstanding in a way that is far too broad and off topic for the subject matter at hand:

For people who don't know the history on this, modern GTK devs (iow Red Hat – some of the same names we see here) tried desperately to make GTK dependent on gvfs. However, it broke everyone's work and gvfs didn't work everywhere, so they were forced to backtrack. To no one's surprise but theirs, GTK still runs just fine without gvfs (except where they deliberately break it, like this gvfs hack interfering with other software), but I'm sure it's still their agenda to make it a dependency just because they want it to be, and the inaccurate information being given here is right in line with that history.

So he's claiming there's some big conspiracy by Red Hat to make everything dependent on everything else for some reason, and that they're lying about what is dependent on what in this very thread to although they were clear where and how the fallback works, and when you need GVFS, and gave non-GVFS suggestions on how to get it to work. That parenthetical, though, is perhaps the height of Guru's absurdity: a library "running fine" except in the cases where it breaks because it lacks a dependency isn't a conspiracy, my friend, that's precisely what a soft dependency is. That's how they work. Hell, something missing its dependencies will continue along just fine until it hits a point where it's missing something it needs and then it will fail. But Guru's conspiratorial mindset is locked in. He continues with the acrimonious verbal abuse, too:

So basically gio is only now supported for gvfs use at most – they won't even think of making or accepting any changes which help other general users of GTK. And I've heard this "please submit patches, test cases, more info", etc. before from these same people. That is their way of just ignoring you – they'd rather waste your time than tell you flat out that they refuse to support gio (or really GTK), and won't accept any changes that do so. At least that has been the pattern of behavior.

This may not be harassment or verbal abuse on the level of what a Kiwi Farmer might direct towards a trans person, but this is pretty clearly unproductive, rude, and dismissive conduct that is unfitting of a bug tracker where people are just trying to get things done. Even Psy, the person Guru is trying to "help" here, isn't really engaging with him that much, probably because he's being too insane even for them. So this is when Emmanuele finally steps in:

Comment 23 Emmanuele Bassi (:ebassi) 2015-06-03 08:54:58 UTC

This will be the only time I reply to one of your comments, and it's also your final warning. Bugzilla is under the code of conduct of GNOME, and you have been consistently rude, dismissive, and flat out insulting in every single interaction with the developers.

Either you stop, or you get your account revoked.

Also, I've been assuming for the sake of argument this whole time that but they weren't. I'm going to post Emmanuel's response to someone else's attempts to summarize and defend Guru's points in full here, because I think it does just as good of a job at deflating them as I could have:

Comment 28 Emmanuele Bassi (:ebassi) 2015-06-03 20:03:07 UTC (In reply to OmegaPhil from comment #27)

#+begin_quote censorship is unacceptable (for the record I have no interest in a 'code of conduct',

It does not matter if you have no interest: the code of conduct for GNOME services exists, and it's enforced on Bugzilla.

if you see shit you call it out,

No, it does not work that way.

You behave like a decent human being, and you afford some level of courtesy to the people that work on the stack that you use. You assume people mean well, and you treat them like intelligent people that are trying to solve problems and work on an open, volunteer-driven project.

o GTK is not supposed to be dependent at all on GVFS.

While GTK does not depend on GVFS, GTK depends on a set of functionality that is implemented by GVFS. If nothing implements it, then GTK simply will fall back to a subset of that functionality.

o In recent times, Red Hat developers have attempted to make it dependent (e.g. the 'soft dependency' mentioned previously).

Red Hat does not enter in the picture; I'm not a Red Hat employee. You can leave you conspiracy theories at the door.

o This broke a lot of things, thus a more serious dependency had to be backtracked.

This has broken nothing. Not showing FUSE mount points from random, unspecified locations that just so happen to be used by some project is not a break in functionality.

o With the current situation and this bug, it looks like the maintainers don't care to be compatible/accessible with client software that already has well-established behaviour, and is not involved with the GNOME software stack.

I've said multiple times that I'll gladly review a patch; I also said that, while I routinely work on the G* core platform, I'm also not a GIO maintainer, thus I cannot guarantee that the patch I review will be join IRC and state your case.

What I'm not going to do is write the patch for you, since I don't have as that I maintain and have to care about.

Since the people in this bug use applications that do not conform to the basedir specification it's entirely up to them to pursue a fix in GIO.

Basically hes very concerned that with this and other issues, important core software is being stolen away from normal non-GNOME usage.

Honestly, if 1% of the energy spent finger-pointing, complaining, and resorting to rude and unfounded accusations were instead spent writing the patch in question, we could have closed this bug already.

#+end_quote

This doesn't seem like unjustified censorship from the GTK/GNOME team, nor does it correspond as abuse or harmful behavior. This seems like a reasonable reaction to a petty, rude troll trying to muscle in on every discussion.

This next one is a talk by Konstantin Blasi at linux.conf.au, and is perhaps the most convincing but that's not saying much. Here's a transcript of the relevant portion, edited for clarity:

"We had the ability to do Windows binaries, Mac binaries, and of course, the Linux distribution from source. There are some issues with the Windows support and Mac support in GTK. The core developer community quite clearly does not consider this relevant, important, or supported. So, there are sub-communities that try to make this work with various I mean, and you run into a lot of bugs and a lot of unexplained behavior. We were at the point where people were saying, 'Oh, this would be a great feature if somebody else would do the UI component,' because no one on the team was willing to deal with changes to the UI anymore. The complexity of doing this, the fragility, the fact that the model system was utterly broken in the way it's designed was very, very, very frustrating. There were lots of things we wanted to do differently, lots of just user interaction changes that we wanted, and we could not find anybody who would help us implement it, and we what's the polite word for terrible? I think terrible, yeah. But the biggest challenge for and I say this, I've said this to these people in person, and I'll the biggest challenge for me with GTK is the attitude of the core community. The community will tell you if you have a problem, they will tell you… eh, now that I can't repeat, there was just reminded of the politeness rules for this conference. The second thing they tell you is you're doing it wrong. The third thing they're telling you, 'Oh, you don't get our vision,' and then they stop talking to you because obviously that's all the help you need. The is utterly impossible to go with a concrete question, saying your documentation states this is what it should do. If I write exactly this code, it doesn't work. This is what it does. How do I get to working code? There is no way to get an answer to this; the only thing you can get is abuse. You can get long flamewars. So if you want lots of comments on your Google+ posts, that works. … Our issue with GTK was we tried for more than a year. We had engaged with a lot of GNOME and GTK developers, and we had come to the conclusion a year ago: this isn't worth it."

This seems pretty bad right? This poor guy is being abused by the GTK team! If they did actually say unprintable things to him, for basically any reason, and he isn't just using that as hyperbole to say they which, to be honest, seems to be to be what he's actually saying, not that they actually told him to go rotate on a then I genuinely would and do condemn that as toxic behavior.

The problem is, I just don't know how much I believe what this person is saying. Even IgnorantGuru never recieved any abuse himself in response to his trolling in their bug tracker, just a bit of light sarcasm but otherwise good-faith discussion, which honestly I think is a testament to the GNOME developers' good will. There were technical disagreements, and the GNOME or GTK people didn't immediately give up and do whatever was asked of them because of those disagreements, but that hardly constitutes actual abuse, and throughout all the rest of these sources, whenever there's been a way to directly check what they've said, I've seen no evidence of the GNOME or GTK people every actually abusing someone at all. The only time any "evidence" of abuse shows up is in vague claims like the one above, backed up with no evidence to support them. Even most of the sources from GNOME haters don't claim abuse. So I've got a choice between believing the word of someone without any evidence so I can see for myself what they're referring to, to make sure it really happened and that my definition of "abuse" lines up with theirs, or believing all of the direct evidence of GNOME's behavior I've seen on their bug tracker and conversations in these sources. I'm going to go with what my own two eyes tell me, especially since I think there are existing ulterior motives for all the acrimony against the GNOME and GTK developers that have nothing really to do with their actual behavior. These are not unbiased witnesses.

Additionally, there's the fact that it seems like he's intertwining the original clip of this video provided to me by the Hacker News person elegantly clipped out the context of the person saying he "received abuse" and "got into flame wars" and "the GNOME developers told him he didn't understand their vision", so that it only included him mentioning bugs and then going to discuss all that, making it sound like all of that happened just in response to him reporting bugs. But it seems like, in actuality, if you listen to the full context given above, there are at least five separate issues that the speaker, and my interlocutor, were both conflating: the issue of cross-platform compatibility, the issue of GTK's "bad design," him wanting to change the behavior of things in GTK, him wanting help implementing things, and the issue of bugs, which the speaker mentions in that order before getting to the GTK team's response to him, thus allowing my interlocutor to conveniently cut out all but the last. The speaker never really makes it clear which responses from the GTK team were to which issues, but if from saying "you're not supposed to do that/that's not supported/important", to silence, to saying "that's not compatible with our vision" (and associated it seems pretty clear which is most probably to correspond to which: responding "you're not supposed to do that" to cross-platform compatibility and him wanting to change the behavior of GTK in some way, responding with "that's not compatible with our vision" to him trying to tell them how they should design their own API (and flamewars ensuing over that bikeshedding, as they always do), and silence when he asks for help implementing his own app.

Could these responses not actually match up, and instead be as disproportionate as he sort of intimates through conflation and obfuscation? Perhaps, but I don't really know how much I can conclude from this. I could probably make a strong conclusion against GTK if any of the other evidence I'd seen so far shows any actual abuse or real hostility on their part, instead of just GNOME developers not being sufficiently "nice" to a troll and not supporting features they don't want to support, but as it stands, I don't know.

Would it be better if GTK was more open and helpful? Absolutely. But this, if we leave aside the conjecture and conflation of issues, just isn't that strong of a piece of evidence. So let's move on.

This is a short one, a rather famous quote from Drew Devault on Reddit:

As a Wayland developer who has had to deal with fighting GNOME tooth and nail over every standard, GNOME can eat shit. What else are we supposed to do but stop supporting them when they refuse to play ball with standards? They're bullies, plain and simple, and take a Microsoft-esque approach to Linux politics - except they just skip "embrace" and "extend" and just go straight to "extinguish". We've spent literal years fighting with GNOME over every standard. They don't just decline to implement standards, they actively work against the establishment of standards at all. Get fucked, GNOME.

By the way, you're welcome that mpv has Wayland support at all. No less than 3 times have I had to confront wm4 about removing Wayland support in general on the basis that GNOME sucks.

Again without clear sources for this where I can go read the logs, and in the presence of all the general GNOME hate that's going around, it's hard to feel like this is actually evidence for anything other than another single person's opinion, this time Devault instead of Blasi. We

why they resisted, what their motivations were, etc, so it's just kind of impossible to say. And honestly, it doesn't seem to me like GNOME refusing to sign off on standards if they don't want to implement them really constitutes "bullying" or Microsoft-esque "extinguishing," so much as them just being stubborn and perhaps overly committed to their vision, precisely because Drew can do exactly what he just said in this comment, and just walk away from the bargaining table, and implement a protocol every other desktop environment and window manager will use, leaving GNOME out in the cold if he wants to, and probably eventually forcing GNOME to acquiesce, since people are free to switch away from it if it doesn't support things well.

Next we have something also mercifully short: a blog comment with more complaining from the Mint people about theming.

Please provide a link towards PopOS's reactions. I'm interested in this.

Joseph is working on adding GTK4 support in Mint-Y.

Personally I won't let any app in our default selection break our theme in Mint 21. I would replace it, or patch it, or fork it, or patch libadwaita, or even patch GTK if it came to that. I don't think it will come to that but that's what I mean by being strict and knowing what we want.

The migration to GTK3 was brutal upstream. With the exception of Mint 12 I think we managed to patch regressions, delay changes and adopt design changes which were good but which broke with the past at a nice pace. We were able to embrace flat themes, symbolic icons, CSD, dark mode, touch UI widgets (toggle buttons for instance) and many improvements after people got used to them and they no longer frustrated most people. We also rejected many upstream changes and stayed true to our own vision of the desktop. Cinnamon is testament to that, we didn't want to lose our panel, our applets, our tray, our window-centric switcher or our desktop paradigm. Looking ahead at GTK4, we'll have the same approach, we'll keep a close eye on the changes, consider what they bring and what they take away, if they're of interest or not, and whether people are ready to move on or not. Developers who jump into GTK4 without thinking or caring what it means for their non-GNOME users, or developers in general who only care about their app integrating properly in a desktop we don't ship, aren't likely to produce apps we'll continue to use, or at least that we'll continue to use without modifications.

I heard people talk about changing toolkits, I agree with their concerns but I think it's too early for that. If you're developing an app with GTK right now and you want it to continue to work well for all users of Linux the solution is simple, stick with what works, what integrates well, what's stable and what is supported everywhere. Yesterday that was GTK+, today that's GTK3.

Again, meh? GNOME is not a DE construction set, it's a DE itself, so of course it's going to be hard to have to continually adapt it to be something completely different, and of course it would lead to downstream consumers of it having to patch it or fork it or move to a different toolkit. There's nothing new here, so let's keep it moving.

Another tabloid article, this time from The Register! In this one, it's talking about what catalyzed System76's decision to write their own Wayland-first desktop environment in Rust (with blackjack and hookers!). It's a long series of "he said she said" back and forth grievances between the GNOME team and System76, first a point-by-point recounting of a GNOME blog post talking about the issues they had in collaborating with System76 in the past, and then System76's response. This article was linked to me as an example of GNOME "vilifying" System76, so let's look at what they said:

Murphy spoke of frustration about the fact that the GNOME extensions System76 develops "break every GNOME Shell release" and that there are "things we'd like to do that we can't simply achieve through extensions in GNOME."

On Tuesday, Christopher Davis, a core member of the GNOME team, accused System76 of "poor behavior" in a post, though added: "I do not speak for GNOME as a whole, only for myself."

He referenced several incidents. Back in May 2018, there was a row over LVFS (Linux Vendor Firmware Service). System76 refused to use it following a discussion with its maintainer, Richard Hughes, and criticized the service's data collection among other issues. In August 2019, System76 described its new firmware manager, which connects to LVFS as well as the company's own firmware service. Davis said: "System76 began using the LVFS and fwupd without any fanfare or retraction of their prior statements."

Davis continued, saying System76 has fixed bugs in its own distro before fixing them upstream in Ubuntu, which Pop!_OS is based on, leading to a complaint from Sebastien Bacher, another member of the GNOME team. We note that, from looking at the comments on that post, including those from Murphy and Soller, the issue is not clear-cut. “Pop!_OS provided patches for both those GNOME examples,” said Soller.

Another issue was development work by System76 on an i3-style tiling manager in GNOME, which Davis said System76 has refused to collaborate with GNOME on, and that System76 made proposals too late for GNOME 40 and "shared misinformation" when these ideas were not included. There was also a reference to a disagreement over libadwaita, a library to make it easier to follow GNOME human interface guidelines. "I do not feel like it is worth my time to engage with System76," said Davis.

Hours after Davis tweeted a link to his blog post, saying "it's finally time to lift the curtain," Soller revealed he was stepping back from System76's Linux distro work.

…

Murphy added that the statements made by Davis were "mostly untrue. He doesn't really understand our situation. Makes too many assumptions about us." He also referred The Reg to a separate GNOME campaign, signed by Davis, requesting that apps are not themed because "all our efforts designing, developing, and testing our apps are made futile by theming in many cases." Murphy believes this was targeting System76.

Reaction to all of this from the community is mixed but by no means supportive of the post from Davis. "I read this expecting to pooh-pooh on System76, but left thinking maybe they have a good case," read a comment on Hacker News.

I recommend you read the full GNOME blog post to get the full content of their issues with System76. It genuinely seems to me, at least from Davis's account, that System76 really did them a disservice, repeatedly spreading misinformation and grievences online via Twitter instead of communicating directly and trying to resolve things. Worse, System76's best reply seems to be a weak, nonspecific "you just don't get it, it totally wasn't like that," and if you actually look at some of S76's interactions with GNOME developers, you can clearly see which side is the petty, short-temptered, childish one that doesn't want to communicate like adults, and which isn't (click on image to go to the thread):

Tobias Bernard on Twitter: "Proper tiling is something we've wanted u… archived 19 Sep 2021 04:59:26 UTC

essentially delivering an ultimatum to this indie open source app developer that he won't consider and is just sad. It's totally within Jeremy Soller's rights, of course, but this isn't even refusing to do something for like, an actual technical reason, or because it conflicts with your vision, or anything like that, and if anything upstreaming System76 tiling would make things much, much easier in the long run for them, so this is entirely just cutting off their own nose to spite someone else's face. I encourage you to read the "stop theming my app" page, by the way, it makes a lot of good points, even as we saw above, where he makes the absolutely paranoid, egomaniacal claim that GNOME is out to get System76, specifically with the "stop theming" campaign, despite there being a million other, bigger distros that also do it.

Once again, we have another theming post, from the Budgie team, complaining about the fact that GNOME isn't a tookit for building DEs, but a completed DE in and of itself, and that it doesn't have a stable public API for theming, and talking about which, agian, is the right move, in my opinion! Here's their discussion of theming:

Linux users have long enjoyed the degree to which they are able to personalize their desktop apps and environments through theming, a tradition dating back to long before I even started using Linux. Reasonable expectations like these are being completely turned on their head by GNOME.

So everything is supposed to have certain features just because they're "traditional" or "expected"? I'm not finding myself very convinced. Plus, if you actually read the "Stop Theming My Apps" manifesto, they never wanted to stop individual users from theming their apps, or their entire desktop! It was a plea to distro maintainers to stop doing that for branding purposes, because if a user purpusefully chooses to theme things themselves, they know something's been changed, that it's nonstandard and not technically supported by upstream app developers, and so are prepared for and expecting minor bugs, and won't blame them on the DE or app developer, thus creating more work for them. If the distro does it, however, it will be assumed to be supported and intentional, and cause problems for upstream developers, as people report problems to them that are really problems with the theme the distro uses. So this is just hyperbolic misinformation. In fact, and lest you bring up the instability of the CSS API, GNOME is so in favor of individual users being able to theme their own things that there's a GNOME app signed on to the "stop theming my app" campaign that allows you to theme your desktop, just in a more rigorous and controlled way that won't break it: Gradience. Not to mention the supported and stable part of the libadwaita colors api.

This is being done by requiring vendors like Solus and System76 to develop their own libraries to handle styling of their own specific applications, fragmenting the look of GTK apps that either use a platform theme or don't use one at all. Through their enforcement of the Adwaita theme in their "platform library" libadwaita, which they pitch as more-or-less the blessed way of adopting their Human Interface Guidelines, they are eliminating both developer and user choice in the process. If you want to support and adopt the GNOME HIG via libadwaita but still offer third-parties the flexibility to make the app integrate well in their ecosystem, you cannot. This introduces a significant regression in the desktop Linux space.

First of all, isn't the entire point of having strict interface guidelines, and a UI library that is designed to basically only allow constructing interfaces that follow those guidelines, restricting choice in order to assure quality and consistency? Also, they were working on a recoloring API that vendors could use to brand things.

Secondly, I should note that the Adwaita theme is part of the UI/UX of a desktop environment (the 'visual API'), so of course the theme would be part-and-parcel of the human interface guidelines. What the hell else would you expect? If you can completely change the layout and look of everything, that's inherently going to make the interface different to use. So I don't know why anyone is surprised that Adwaita is hardcoded into….*libadwaita*. It is quite literally in the name, people.

Again, this seems like another case of people wanting to use GNOME's stuff for the convenience it offers, but not wanting to actually use they want to take advantage of GNOME's labor, but don't want it to have any GNOME touches, any whiff of anything GNOME-specific, or any element of GNOME's design philosophy, on it, all the same. They both want it to be built for them, so they can conveniently and easily follow the HIG, but also be totally flexible to however they want to modify some aspects of the toolkit that /effect the HIG. They want to have their cake and eat it too, essentially. Honestly, the sentence (paraphrase) "we want to use libadawaita for implementing the HIG, but also still offer theming (i.e., not use Adwaita or follow the HIG at all, with our library that is for doing exactly that)" is the height of absurdity. GNOME finally did what everyone wanted and split out their GNOME-specific code into a separate library, and left GTK 4 completely platform-agnostic, and now people want to use GNOME's own library too, and are complaining when it's too… GNOME-specific. It's like the classic webcomic:

There are some new bits, though. Well, new for us, at least. There's the trite, stock accusation that GNOME is "suboptimal" on the desktop and a "mobile interface" (we will deal with this later):

While we have been consistent in this vision, though certainly not without flaws in its execution, we have seen a significant shift from GNOME's development efforts and vision being focused from their desktop experience, to a heavier focus on mobile-to-desktop application scalability and a more touch-oriented, almost iPadOS like user experience that does not (in our opinion) provide the most optimized experience for laptop and desktop users.

And grandiose accusations of groupthink because GNOME has a vision it wants to pursue, and doesn't want to serve every possible user that complains (and I should add, there is a 'silent majority' of users who use and love GNOME every day):

This is something I have noticed over the years as the maintainer for the GNOME stack on Solus and has become especially apparent in the last few years while I have been the lead on Budgie. 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.

As well as accusations of, essentially, cancel culture:

To make matters worse, when some improvements were proposed by an engineer at System76 to libadwaita's Recoloring API, which is their alternative to theming that is specific to recoloring various elements of GNOME apps and is app-specific (not system wide), these improvements were rejected on the basis that some of the GNOME developers disliked the opinions expressed by the engineer on social media. … Instead of debating more on technical merits, these developers are instead trying to devalue and discredit the contributions by intentionally misconstruing the opinions expressed by the engineer, attributing malice where none existed, and claiming the individual was "flamebaiting" to get attention.

…because GNOME developers didn't want to work with System76, who are transparently petulant and childish to them, routinely go and spread misinformation and grievances online instead of communicating with anyone, and most relevantly, take quotes from their own communications with GNOME developers out of context and use them as rage bait online. does that count as merely a "dislike" of some "opinions," and a petty rejection, or is this obviously someone you wouldn't want to spend your time working with work with?

Additionally, looking at the actual thread, people from GNOME actually do discuss the technical merits of the merge request with the PopOS team, and several app developers not from GNOME also chime in to say that they don't like or want PopOS's solution, and they discuss the technical questions why. Things only take a turn away from the technical discussion when one of the app developers (I believe) mentions System76's behavior towards GNOME on social media as an explanation as to why GNOME devs might not want to collaborate with them, and then a discussion begins trying to explain to the System76 person how and why their behavior may have been unproductive.

the worst you could say is oversensitive, I guess, but I don't think that's true either.

And if we look at the things linked by Alice, we see that, again, System76 is being the asshole here, pretty clearly. Delivering grandiose ultimatums in an unproductive manner:

Jeremy Soller on Twitter: "Something () NEEDS to realize is that … archived 18 Sep 2021 20:20:25 UTC

Pretending that dark mode won't work on GNOMe (I'm literally using it right now, it does):

https://web.archive.org/web/20210901165846/https://twitter.com/jeremy_soller/status/1433085221994258435

and posting flamebait to rally the haters (whether you agree with the quote or not):

Jeremy Soller on Twitter: ""First and foremost the recoloring API is … archived 18 Sep 2021 19:35:13 UTC

I think GNOME was more than justified in the way they acted.

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.

And yet again, more complaints that the GNOME developers don't do what the downstream developers want with their own time and their own project, insisting that people who don't contribute to a project should some how have a right to dictate how it works, and calling wanting a less customizable experience somehow "anti-user" (which, again, would only be true if there weren't other more customizable options, or users were somehow trapped on one DE).

Why can't Ubuntu, Mint, System76, and whoever else just fork GNOME, if they don't like where GNOME is going, instead of trying to use the GNOME devs as slave labor and crybullying others when they don't get their we can see this in the fact that System76 is, in fact, now developing their own entire DE from scratch.

Although it purports to demonstrate some kind of systemic problem with GNOME's developers, our next post does nothing of the sort. Instead it catalogues an interminable how dare GNOME require OpenGL 3.0 in 2023 (nevermind that 3.1 has become the de facto widespread standard across and bugs, the likes of which one could easily replicate for any other desktop environment, even, or perhaps especially, the vaunted KDE, and various features the author is personally mad they didn't implement fast enough. The only really egregious example is this:

Five years ago an issue was raised regarding mutter in Wayland not allowing applications to inhibit the screensaver, making tasks like watching a movie something unbearable [25]. The fix would involve implementing support to a well-established Wayland protocol that at that time was already implemented in KDE and Sway. Only four months ago GNOME finally addressed the issue, but not without embarrassing discussions, including GNOME developers trying to bend logic:

#+begin_quote Most people either don't seem to watch long movies on their desktop or just don't seem to be bothered by the bug.

#+end_quote

Which, like, yeah, that's dumb, but that quote is taken out of context. This isn't the GNOME team rejecting that it's an issue at all, saying it isn't a feature they need to get around to implementing, or dismissing anyone's complaints. Here's the actual full quote:

I totally understand the frustration, but "basically unusable" is an exaggeration. Most people either don't seem to watch long movies on their desktop or just don't seem to be bothered by the bug. Why else would we receive so few reports about the problem in 5 years? … I want to reiterate though, that is is a bug, and one that GNOME shouldn't still have.

So yeah, I think we can leave this disingenous article alone. GNOME doesn't implement features fast enough for them, they introduce bugs sometimes, and that means they're the devil incarnate and incompetent developers. Great.

and the catalyst for this entire we have this bug tracker issue and this Hacker News thread about it. What we're going to do here is look at conclusions the people on HN draw about GNOME's behavior from reading that issue, and then look at what actually happens in that issue, and see if they line up.

chris_wot: I have no sympathy for them. They implement a spec and make a big song and dance about being open and standards friendly… and then when they don't implement the standard correctly they say they have implemented it correctly, argue about it and then when they are proven incorrect they just close the ticket, even though they could make small changes to fix the problem.

cullmann: I as Kate maintainer can not understand their position in that bug. I see that one might forget about the implications of that rename, but now it got reported and the fix would be, at least the simple one, to just keep the old icons for these names. That would have zero bad impact on 'modern GNOME apps'.

Intralexical: That would make sense if they cared about solving the issue. Rather than about proving they're right and showing they're in control.

The specific issue and facts don't actually matter. Y'all said something that was different from what they were already doing/thinking, therefore, you must be wrong.

mook It sounds like an alternative where they just don't pretend they support the thing the don't support was proposed, and shot down because that means they won't show up in UI that only lists things that support the thing?

… And they also control the UI in question?

meibo: Wow, those RedHat guys in the gitlab tickets and commit descriptions related to this are insufferable. Is this what happens when you get paid for open source work?

LightFog: There does seem to be a culture of contempt for the dribbling masses (aka users and application developers) ruining the beautiful visions of RH devs.

Intralexical: Nobody should be surprised anymore when GNOME pulls some shady and technically questionable crap to try to make their "product" look better by actively breaking other people's work.

Once again, we're presented with a nearly unanimous narrative that sounds really horrible. Let's look at what this thread seems to be saying is happening:

1. GNOME broke these icons for no relevant reason
2. The GNOME devs are being insufferably contemptuous of people just asking for a simple fix to a problem
3. They're advertising their icon theme as supporting a standard it doesn't, a standard that basically all other non-GNOME apps use
4. They're refusing a simple fix that doesn't cause any problems at all

Ouch. Well, let's actually take a look at the bug tracker thread for ourselves and see what's going on.

We open with the issue itself:

Nate Graham: [Here I use the copy icon as an example, but the issue affects everything]

The Adwaita icon theme has an icon-named edit-copy-symbolic for its copy icon.

The FDO icon theme name spec specifies that this icon should be named edit-copy; see https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html.

As a result there are 18 years of FOSS apps that ask the active icon theme for edit-copy, not edit-copy-symbolic.

When Adwaita is the system's default icon theme, and such an app asks for edit-copy, it's not found. Per the icon loading spec, the icon loader will chop off the last part and look for edit. That won't be present in Adwaita either. Hence no icon will be found, and the the app will have a blank space instead of a copy icon. Users will file bug reports, complain on Reddit, and make 20-minute YouTube videos crooning "Whyyyyyyyyyy??????" into a camera.

Now, I understand why Adwaita wants its symbolic icons to have -symbolic appended.*In KDE we like this convention you came up with, and we're moving towards it as well, and porting our apps to ask for edit-copy-symbolic. However we retain the old icon names for backwards compatibility with FDO-compatible apps that have not yet adopted this convention.* … Consider adding or re-adding compatibility symlinks, so that apps outside of GNOME and KDE aren't missing almost all of their symbolic icons when using Adwaita.

So, right off the bat, already we're seeing some differences from the dominant narrative in the Hacker News thread. It looks like this isn't something GNOME did completely at random, or even by themselves, but something GNOME and KDE and probably other DEs are all doing together, it's just that GNOME is moving a little faster and cares less about backwards compatibility in the meantime. That's still not great, but let's see how the discussion develops:

Jakub Steiner: This doesn't feel very actionable from my side. the -symbolic suffix separates the different recoloring behavior of symbolic icons. Linking to symbolic icons to expose them in the non-recolorable codepath will introduce all sorts of issues. adwaita-icon-theme is not a generic icon theme from the 2000s anymore. It's scope narrowed to serving a few core GNOME apps.

Now things are beginning to diverge from the narrative a little bit more, huh? These icons have different names because they fundamentally don't have the same behavior as the old icons they're replacing, so just linking from the old icons to the new ones might cause bad behavior (perhaps unreadably low-contrast icons or something). Please note, they're doing this in order to be able to support the recoloring API they're working on to let people theme safely without using raw CSS themes. Those evil GNOME devs! Moreover, the developer points out that GNOME isn't designed to be a generic icon theme anymore, but is a GNOME-specific icon theme, for the GNOME apps (we'll see why in a second). I will admit this is phrased in a somewhat condescending manner, but considering the tone of the original issue, and the fact that they're not engaging in any other bad behavior honestly, a little condescention is forgivable. Let's continue.

Nate Graham: If Adwaita doesn't want to be an FDO icon theme, that's fine. But the problem is that Adwaita is advertising itself as an FDO-compatible icon theme … As a result distros are setting Adwaita as the default FDO icon theme, and then apps that expect the default icon theme to be FDO-compatible get broken in the way I described. … It sounds like maybe you should remove the metadata that advertises Adwaita as being an FDO icon theme …

Seems fair enough. Except, a quickly following this, Nate realizes that GNOME already did this:

I see with 85e22163 you have removed some metadata.

Let's look at the commit:

Relying on adwaita-icon-theme as the all encompassing icon theme it long isn't is going to break in all sorts of ways. Don't confuse old timers into thinking adwaita-icon-theme is a good fallback theme for KDE.

So they've explicitly removed all of the information specific to acting as a fallback icon theme for KDE, so that properly programmed KDE apps wouldn't end up in this situation, since the icon set is not an FDO compatible icon theme anymore. So they explicitly aren't trying to advertise themselves as something they aren't, right? But Nate continues:

Nate Graham: However that's not enough; with that commit applied locally, Adwaita still appears as an FDO icon theme on the Icons page of KDE's system settings app.

I think you also need to delete this part:

#+begin_quote [Icon Theme] Name=Adwaita Comment=The Only One Example=folder Inherits=hicolor

When I remove that stuff locally, Adwaita disappears from the Icons page as I would expect. That's the correct way to de-register Adwaita as an FDO icon theme.

#+end_quote

None of that looks to me like it's advertising itself as a workable that seems like it's just there so it's discoverable to Adwaita applications at all. It already isn't actually advertising itself as compatible with KDE apps as a fallback icon theme, but their software is still picking it up for some reason, and their solution is to just ask GNOME to make their icon theme completely undiscoverable at all. And sure enough, Jakub says exactly this:

Jakub Steiner: I'm afraid you're asking to break a-i-t. Nothing that remains hints at a-i-t presenting itself as a fallback theme.

I don't feel like investigating the fallbacks of the KDE side of things, but that would be my suggestion to start your journey on why your app breaks by depending on adwaita-icon-theme.

Nate reiterates the same point again, so Jakub expands:

Jakub Steiner: It doesn't advertise itself as such anywhere. The Inherits line? That just tells the lookup to go searching for a missing assets in the inherited theme, hicolor in this case.

Nate disagrees, and finally gives some sources so we can go look at them:

Nate Graham: It's right here: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/index.theme?ref_type=heads#L1-L5

Together, that metadata says, "I'm an FDO icon theme. If I'm marked as the default one, please use me as the source of icons for any app that asks for themed icons." Reference: https://specifications.freedesktop.org/icon-theme-spec/latest/ar01s04.html

That first link is just the Adwaita icon theme entry he already showed, so we don't need to look at that. But let's look at the FDO icon theme spec and see if any of the properties set by the Adwaita icon theme indicate it's an FDO-compatible theme:

I don't see any specific property that is supposed to indicate implementing the FDO icon theme spec completely, which seems to be what the GNOME devs are keying off:

Jakub Steiner: That's your misinterpretation.

Maybe what Nate is referring to is the idea that simply having an INI file with this format at all indicates you must be a fully-FDO-compliant icon theme? If that's the actual behavior KDE's apps have, under that assumption, then I can sort of see where he's coming from, but (1) he never says that and (2) it's just an INI file specifying the icon set so it's discoverable to GNOME apps and has some metadata attached to it, that's not really FDO-exclusive, and why not use the same format for FDO and non-FDO icon sets, so you can easily discover them both, instead of a bunch of different organizations for each? It seems weird to assume that any file that happens to have some of the basic properties of a standard adheres to that standard. Maybe I'm too used to files with explicit file type and version headers but that would be odd. I think there's definitely two sides to this, but the issue isn't as clear cut as the KDE developer seems to think. Another commenter, Michael Catanzaro, seems to agree with my interpretation, although he doesn't seem to see how it's helpful: "I guess theoretically you could say 'adwaita-icon-theme implements the icon theme spec but not the icon naming spec.' But I'm not sure this would be a very useful state?"

In any case, this doesn't seem to be a case of the GNOME developers intentionally setting their icon theme to claim to be something it they seem pretty cleary they don't want it to show up as something it isn't, even going so far as to suggest adding a full icon theme for KDE apps to fall back to if they can't find an icon they're looking for, he just doesn't want to keep legacy icons around in GNOME's own icon theme just for legacy KDE applications, which seems reasonable to me:

Jakub Steiner (a) I'll be happy to roll out some legacy fullcolor icon theme for the fallback to use downstream, but it's hardly a reasonable proposal to continue shipping ancient fullcolor assets for KDE to fall back to here.

This doesn't seem like a brick wall of unhelpfulness at all. Unfortunately, Nate misunderstands what he was saying:

Nate Graham: Again, KDE apps are not falling back to anything. They are asking for icons in the active icon theme (not any fallback icon theme) and those icons are missing with Adwaita.

He thinks they're still discussing the idea that KDE applications might be erroniously treating Adwaita as a fallback theme, when Jakub is actually proposing adding a fallback icon theme in case, as Nate described in the original issue, an icon can't be found. So, sadly, this reasonable suggestion falls on the sword of FOSS developers' communication skills.

At this point, another developer enters the discussion to point out that most modern Linux applications don't use or support icon themes, but bundle their own icons, and (as we see with the fact that symbolic icons have different behavior than hicolor icons, which is the source of this whole controversy in the first place) when they do, the behavior is different enough that implementing the spec would be actively misleading:

Matthias Clasen: All of this is fighting yesterdays war.

Icon themes are not a very prominent feature in current app development, and demanding that we do lots of extra work to implement specs that were conceived in a very different time and environment is not helping the situation.

He even points out, as I hinted at above, that the reason the Adwaita despite the simple reason that there's no reason to duplicate discovery code and create a whole separate alternative way to specify icon theme metadata for non-FDO-compliant icon themes just to be different so choosers that expect everything with an Icon Theme INI section to automatically be fully FDO-compliant don't have to change:

Matthias Clasen: We can't do that until there's alternative apis for apps to rely on. Until then, Adwaita will still be an icon theme, so apis like GtkIconTheme can be used to load whatever icons exist in it.

And I think its a misconception on your part that "registering as an FDO icon theme" comes with any requirement - there's no such thing

Unfortunately, Nate is a brick wall and refuses to listen:

Nate Graham:

Registering as an FDO icon theme creates the implicit assumption that the so-registered theme is actually usable by apps that request themed icons from an FDO-style icon theme. Maybe this is an implicit assumption rather than an explicit one, but it's still clearly there. … All I'm asking for is symlinks …

To which the GNOME crew points out:

Michael Catanzaro: The problem is the symbolic icons are not appropriate replacements for the non-symbolic icons, because they have to be recolored or they don't work well. I'm not sure whether Qt even supports recoloring. Older toolkits like GTK 2 do not. Then maybe newer GTK relies on the naming to decide whether to recolor (not sure)? So it's not as compatible as you'd like.

The easy solution is to bring back the fullcolor icons mandated by the icon naming spec. I don't know what else to suggest.

I recommend reopening this bug, because distros will stop using adwaita-icon-theme if we don't figure something out on our end. Kate isn't doing anything wrong here.

So the GNOME developers are actively offering solutions, even pretty labor-intensive ones, to try to get this working and make everything ironed out. Nate just completely ignores this offer of an easy solution that satisfies all parties, though, as if it was never offered, and offers two interesting but not necessarily better suggestions about this:

Nate Graham: I gather that in GTK 3 and 4, re-coloring is only enabled for icons that end with -symbolic? Maybe that could be relaxed, in favor of a more sophisticated check of some sort. For Breeze icons, the determination for whether an icon is re-colorable or not is baked into the icons themselves via embedded CSS stylesheets, so no special naming scheme is required. … To work around this issue, we provide a dedicated dark version of the Breeze icon theme with all the icons defaulting to a light color so that if the toolkit doesn't support re-coloring, the icons' standard colors are at least correct. Such an approach could theoretically work for Adwaita too.

And the GNOME developers even consider one (!!) despite offering their own solution that should've satisfied everyone:

Michael Catanzaro > To work around this issue, we provide a dedicated dark version of the Breeze icon theme with all the icons defaulting to a light color so that if the toolkit doesn't support re-coloring, the icons' standard colors are at least correct. Such an approach could theoretically work for Adwaita too.

Maybe.

I could see a possible future where the fullcolor icons are automatically generated (and recolored) from the symbolic sources. To us, the fullcolor icons are legacy, and Jakub clearly doesn't want to maintain them anymore. Maybe just not having them in the git sources would suffice.

Jakub then joins the conversation again to explain why each of the proposed solutions has problems, but reiterates that he is committed to solving this too:

Jakub Steiner:

Kate being broken because it's missing icons is a severe break that I wish to find a solution for, but it can't be one of:

• Maintaining a set of fullcolor assets in a-i-t that isn't actually used by core GNOME apps, not [sic] Circle apps or any modern maintained apps.
• Symlinking names to -symbolic variants which will break recoloring (and probably introduce more issues in context we don't foresee).
• Mangling index.theme metadata so adwaita-icon-theme drops from the icon lookup machinery. While it may fix Kate, it will break GNOME.

Something that might work, but I'm fairly skeptical about:

Inheriting from a legacy icon theme (tango-icon-theme). Potential lookup issues if fullcolor takes precedence over -symbolic.

Will do some testing for the last one.

In response to this, Nate again completely ignores the offer on the part of the GNOME devs to create or choose a fallback icon theme to provide the icons KDE applications expect, and drops some important information about the situation: KDE is the only set of applications and only desktop environment that relies on FDO icon themes by default, and everyone is increasingly moving away from using FDO icon themes. So in actuality, this isn't really GNOME refusing to be compatible with it's KDE still holding on to something that nobody else really does anymore, and asking everyone else to slow their roll, despite everyone else being ready to move on, just to make their applications more compatible:

Nate Graham

Maybe you folks didn't think there even were any remaining consumers of FDO icon themes. I could see how that seems like a reasonable conclusion to reach if you didn't look at any KDE apps; I'll admit that in my own investigations, I have found no apps outside of KDE that do use FDO icon theming by default (most that do support it make it opt-in, and bundle needed icons). However in KDE we have thus far adhered to the FDO icon theming spec and use it by default. We have over 200 cross-platform apps, so hopefully we're not chopped liver. :)

Now, it is fair to want to support two hundred applications, especially ones as featureful and well-maintained as KDE's, so I won't say I'm completely on GNOME's side here, but this does paint a rather different picture than the Big Bad GNOME just breaking everyone else's shit just to be mean. This looks more like a disagreement over how much backwards compatibility is important, and how to implement that backwards compatibility without breaking other things when there aren't really any great options, all to have compatibility with one desktop environment and its applications (KDE), where the GNOME team repeatedly offer solutions and are willing to commit labor and testing to make them happen, but the KDE people completely ignore their offers.

A GNOME developer even agrees that they can make their icon theme metadata format even less compatible with FDO so nothing is "tricked" (Nate's words) into thinking it's an FDO compatible icon theme just because it has some shared metadata properties with generic names, and agrees that this was poorly coordinated:

Sonny Piers: > I have found very few apps outside of KDE that do use FDO icon theming by default (most that do support it make it opt-in, and bundle needed icons).

I agree it sucks for KDE apps, and surely we could have better coordinated. I would have hoped distros to help catch this. … > It sounds like you folks should work towards […] doesn't use the FDO icon theming machinery at all Yeah we've been talking about that for a while - I will bring it up at GUADEC and see if we can make progress.

They then ask an all-important question:

Out of curiosity is it KDE intention to keep using host icon themes by default?

To which Nate responds:

Nate Graham: So far we have no plans to abandon FDO icon theming in KDE. On the contrary, we have desired for a while now to try to rehabilitate the FDO specs for it to improve the situation, and (a) being their new maintainer is a promising development from our perspective.

It's pretty clear that in its current form, FDO icon theming only works if you control your own icon theme, which is why KDE and some other DEs with their own icon themes (e.g. Budgie with their own apps, Cinnamon with Xapps, XFCE apps) still happily use it. … The fact that 3rd-party apps without their own icon themes have largely abandoned it is a sign it's not working out as originally envisioned.

So basically, this spec only works for applications developed directly by DEs who also control the icon themes, so that if you need a new icon for an application it can be added to the icon theme, but third-party applications have basically stopped using it. And so some DEs are still sticking to it with their own applications, including KDE, but most of the ecosystem is moving away from it.

At this point, the other threads essentially repeat the same discussion, although it seems like eventually falling back to Tango, for now at least, was agreed upon.

More importantly, though,*the decision of the GNOME team seems to be agreed-upon even by non-GNOME developers*:

Jakub Steiner The icon naming spec was created in a world where we believed we can come up with a fixed set of names and metaphors and cover a large enough base that we can achieve interchangeable icon themes. Users would replace a full icon set and get a completely different look without breaking all apps.

It was naive to think there will not be that one extra addition. No matter how much resources you'll throw at the problem, icon themes means apps will have a broken or off-looking icons. Widening the coverage will simply make it impossible to pick the right icon for the appropriate context and you'll just have harder times updating your assets. Unless you think Tango & Crystal were the pinnacle.

Christoph Cullmann I can agree with that, Breeze still tries to cover most stuff, but I see that issue. And I can even live with if we agree that themes are dead in the future and we all hardcode something or the different libs provide different ways to do that theming. I would just have hoped that would be first raised between all projects to allow us to fix our side and not that we now are in a situation where the side that seems to believe most in the old spec is just stranded and we have broken stuff there out in the wild.

Nate Graham That's what I believed as well until yesterday, but when I went looking for evidence to support that position, I unfortunately found the reverse: that most 3rd-party apps already ignore FDO icon theming. So (a)'s earlier "yesterday's war" comment makes more sense to me now.

It prompted me to open https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/132 to see if there's anything that can be done from the spec perspective. I get that GNOME folks will probably still ignore it, that's fine, it's their right, but maybe those of us who do still care about icon theming can work to make it better for our own use cases even if GNOME doesn't participate.