The “don’t theme my app” thing just tells me that GNOME/GTK+/Adwaita aren’t built in a way that gracefully handles theming, or that devs building apps with them are doing things like hard coding colors when they should be using dynamic system colors such as those provided by UIColor[0] in UIKit.

[0]: https://developer.apple.com/documentation/uikit/uicolor/ui_e...

Supporting themes imposes an ongoing technical burden across the whole ecosystem. It's not worth it. You don't hear people say "I hate macs because I can't make my title bars purple".

You do however see many complaints when an app doesn’t support dark mode (which is closer to the typical use case of themes).

Additionally, see my other comment about accessibility, which is also negatively impacted by hardcoded UI appearances.

Dark Mode is first class in the next releases of GTK4 and LibAdwaita. It'll be available in GNOME 42 and Fedora 36.

Yep and that’s great, but there are still other legitimate uses for theming. One of mine is cutting down padding to reasonable levels — GNOME is much more usable to me when using a theme like Nordic or Skeuos, both of which do that.

Or putting the scroll bar back, or getting rid of the awful client side decorations.

This attitude is why we can no longer have stuff that doesn't only come in "light theme" or "dark theme". I consider this a regression. Let me theme my damn computer the way I want. It's called a Personal computer for a reason.

It is silly that dark mode isn't regarded the same as just switching themes. Forcing its adoption however breaks dependency on non-themable components so its popularity is still a net benefit.

There's a difference between "we'll test and support two color schemes" and "we'll design ui with parametrised colors, shapes and text sizes which can adjust to any change and still be usable". If we settle on bright/dark/colorblind mode selectors that everyone expects to be supported, I'm happy. I've seen themes in the past and there was always a few apps which just can't resize elements in the expected way, or the backgrounds don't tile correctly, or ...

Ok, then don't support it. But don't patronise me. Don't tell me I couldn't possibly wield the power of recolouring a piece of UI without hurting myself, and deny me the chance to even try.

No one can deny you anything with FOSS. Go ahead, edit everything, just please don't complain to the developers that something broke because of that.

But libadwaita hasn't taken away the ability to try? You can still load custom themes through GTK_THEME and specific CSS through ~/.config/gtk-4.0/gtk.css.

Don't get me wrong, I'm glad to have any measure of control at all. It's just that I'm frustrated that we had infinitely more capable theming system already in place, and it was broken.

I want customizable color schemes and fonts and sizes. It's nice as a user to pick full-on custom themes. Sadly even though Qt is based around theming, I had to turn off theming for semi-customized controls (colored sliders) to make them render correctly on Windows and Linux Breeze/Fusion. And it's more work to verify my app looks good across OSes when QButtonBar and QFormLayout change appearance on different OSes. So finding a good solution is nontrivial.

I'm quite sure you could change system colors willy nilly in OS 8. It was great fun. I miss that part - the feeling of having "your own" system.

Since customization where pretty standard back then, it feels like product managers pushing their "vision" rather than technical difficulties preventing that nowadays.

Kaleidoscope and later on Appearance Manager in Classic Mac OS were so much fun. No OS theming system I’ve encountered since have been as capable as those were.

Ye I wonder what fantastic APIs were actually exposed. I remember some 3rd party screen saver I had. Where like Goofy peeked out of folders and Donald Duck was cleaning up some file mess. I mean, how could you even program that?

I think it was on the real desktop, not some bitmap, but not too sure.

If not for scrollbars color, I certainly dislike the macOS GUI for its straightjacket approach. (Also, poor window management.)

I wish Gnome folks did not keep on copying it more and more. I see why it's easier to do, but KDE somehow manages.

(And if one thinks that Apple UX design can't go wrong, remember Macbooks from a couple of years ago.)

I get what you’re saying but I find GNOME more evocative of iPadOS than macOS. It’s almost exactly what you would get if you tried to create a desktop environment using an iPad as a starting point.

macOS still has several traditional desktop affordances that are eschewed by GNOME, like full menus (not just hamburger junk drawer menus) and customizable toolbars.

I switched from Mac to Linux (in 2008-2009) because I could understand it and make it my own, among other things with theming.

I do say that. The light-grey on top of light-grey theme means a lot of times the only way to tell which is the foreground window is by looking for the 3 colored dots.

MacOS at least lets users choose the accent color: https://osxdaily.com/2020/07/24/change-accent-color-mac/

I feel like partially the movement happened because some themes made the apps unusable and then instead of blaming the theming, users blamed thee app developers instead.

In some cases badly designed themes (like dark gray labels on black backgrounds) are the culprit, but most often it’s a result of the app developers hard coding colors in their UI elements assuming all users will be using a similar theme.

That’s not only bad for custom theme users, it’s bad for accessibility since there’s no way for increased contrast modes to modify the hard coded colors. Apps really just shouldn’t hard code colors.

Agreed, definitely. OS should provide basic colorsheets that the apps use, and those sheets should be freely modifiable.

Which is why I really like KDE.

KDE (or rather Qt) goes even further and still let's you completely change the way interface elements are rendered, which is great because it means you can use the same look across versions if you want to and are not beholden to the latest design fad.

- Gnome includes high contrast and dark modes and encourages app developers to test against them.

- Requiring apps not to use custom colors alone won’t fix it. Any bespoke UI element an app includes is at risk of breakage when a custom theme redefines the entire world. https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-a...

I build bespoke UI elements for iOS apps all the time and building them in such a way that they look and function correctly not only across light/dark and accessibility modes but also future OS versions is not that difficult, and with how they’re built I don’t see them breaking even if iOS took on a radically different appearance. They might not match perfectly but usability will not be impacted.

If this is not reasonably possible with GTK, then it seems pretty clearly like a weakness of how GTK handles themes. Personally, I believe that CSS is ill-suited for the task and is responsible for many of the issues depicted in that blog post.

> not only across light/dark and accessibility modes but also future OS versions

When Apple makes a future OS versions they are expected to avoid breaking apps.

The comparison here would be not to future iOS versions, but to arbitrary jailbreak tweaks that overhaul the look system-wide. You're not ensuring that will look good with your app ;)

This is exactly the reason.

But people seem to deliberately obscure why the Gnome devs are doing this and instead accuse them of being lazy and/or dictators etc.

Removing themes because they have in some rare cases caused problems is a pretty lazy response.

GNOME has design zealots similar to Apple, but with more bizarre choices.

Their whole crusade against tray icons and a usable task list have been painful to deal with. Do they just not like multitasking??

It's sad too, because there's a lot of nice UI/UX in there, it's just buried under all sorts of crazy choices. Thankfully, there's extensions to restore some of the missing functionality.

https://extensions.gnome.org/extension/1160/dash-to-panel/

https://extensions.gnome.org/extension/2890/tray-icons-reloa...

These two fix those weird design decisions and make GNOME a pretty good desktop.

Status icons were built on old and fractured technologies. They are coming back. Designs and technical discussions are happening right now.

But why discontinue the old method before the new one is ready? This leads to an awkward UX and disinterest by developers, during the time there is no option.

GNOME probably imagined it had enough market power to persuade app developers to change their design. Also GNOME likes to emphasize "distraction-free" computing so the designers probably thought status icons are too distracting for users.

A dedicated tray is a concept tied to windows 95 style UX. I hope the new designs are more about standardizing ways to indicate various statuses and actions of "the app" broadly, without dedicated status icons. For example download progress is still only an Ubuntu Unity protocol that KDE also supports because they can but it's all not freedesktop standard.

It's not just Linux that suffers from outdated tray APIs. It is the same on Windows. To create a status tray icon button, you need to call the Win32 Systray API (the oldest Windows subsystem, forget about using WinUI or UWP). The way apps like Google Drive and Dropbox do their fancier systray popups is that they get the x,y coordinates via the systray API (NOTIFYICONDATA passed to ShellNotifyIconA) and then render a chromeless window at the location with a slide up animation via something like Electron. I don't think the default systray menu can be styled to any reasonable extent.

And it works pretty well, at least Win32 is less susceptible to GUI civil war going on since Windows 8.

How about applications that are controlled entirely from their status icon, like dropbox or vpn apps? Fedora, which normally champions GNOME, is beginning to acknowledge that status icons are here to stay whether GNOME designers like them or not: https://pagure.io/fedora-workstation/issue/246

How about desktops that don't have anywhere to put status icons? i.e. what if I don't want to have any panels? Working as a normal window should be an option in all applications.

With "old" method under X11 the icon was just a tiny window the application created that was then embedded in the tray window and you could do basically anything with it. This caused problems with transparency though so for the sake of a prettier desktop (and because this approach would not work with Wayland) we got a more limited D-Bus protocol where you only get an icon and a menu.

Very interesting. The current state of tray icons is one of the most painful aspects of desktop Linux, in my opinion. Where are these discussions happening, and what kinds of plans are in the works?

The discussion is happening on the Freedesktop GitLab instance.

That's great to hear! It does bring this to mind though https://xkcd.com/927/

Is there a similar reason GNOME doesn't have a convenient task list?

Plank is probably the dock you want.

I still dislike the gnome3 title bar with the icons. As you say, unlabelled mystery meat and hamburger menus.

I'll admit, part of my dislike for the new title bars is probably irrationally rooted in just wanting things to stay like they were on windows 98 when I first became familiar with computers, forever, and never to diverge too much from that. But those unlabelled icons, they really do puzzle and frustrate me. On websites too

Unlabeled icons are terrible. I use Gmail more than any other application outside of dev tools like my editor and my terminal, and I use every single one of the message operations (archive, snooze, add as task, report spam, etc.) at least occasionally. After a month with a new work Gmail account I realized I was still waiting for the tooltip to pop up before clicking the buttons, just to make sure of what I was clicking on. Fortunately, Gmail lets you switch to text buttons. Now when I want to snooze a message, I just click snooze, instead of thinking, "This button is a clock, I bet it's snooze, but hold up, what if it's another time-related operation I'm not thinking of... okay, confirmed with the tooltip, now I can click."

And that's for a button I click several times per week!

I still use the html gmail, that's getting harder to access all the time (and which google now just straight up ignores being set as your default view, and gives you the javascript view anyway unless you manipulate the URL)

Me too! I hate this.

it's made worse by the fact that tooltips are unavailable for mobile users

The convention for mobile UIs is that tooltips show up upon long pressing the buttons. Unfortunately, sometimes that does nothing, or something else entirely (e.g. start dragging).

I have the same gmail issues and didn’t realize you could change to text labels!

I disagree with the notion that wanting the interface to stay the same just for the sake of it staying the same is irrational.

Yup... Client side decorations is why I don't use Gnome3.

> I still dislike the gnome3 title bar with the icons.

It's a key part of touch readiness. There's even a Windows-like theme for Gtk3+ that looks really close to the original, you might like it better than the default look.

Why do we have to suffer it on the desktop though? It’s so damn hard moving windows on gnome without setting something off accidentally. Especially with the shitty touchpad input devices.

My mac laptops aren’t touch screens and they get this usable.

The whole gnome desktop makes me want to stick forks in my eyes.

> It’s so damn hard moving windows on gnome without setting something off accidentally.

I'm not sure, I've never run into this? The headerbar itself, with its labeling text, works just fine as a mouse/touch target.

Yeah, clicking and holding on a header bar button will still allow you to grab the window without firing any action. It's quite handy, especially with a touch pad.

You don't have to target a button at all, that's quite silly. Aim at the window label. Labels have always been connoted as "plain text" with no actions associated, so they're quite intuituve for that purpose.

Of course! But when you're using an application with a fairly busy header bar (like Nautilus or Epiphany, which don't have any labels) it can be useful to just point at the first pixel you come across without having to aim for a blank interval between buttons.

Super+drag anywhere on a window. It should be a must on every single OS.

This is completely Inferior to dragging a titlebar as it requires twice as many hands.

On the other hand (ha) it does not require any aiming. I can super+drag windows into "aero snap" targets in milliseconds because I don't have to spend any time on finding the header bar.

Which makes it a great addition to title bar dragging but not a replacement.

Depends on the user to be honest. I quite dislike title bars (Especially if fairly bulky.) and so I remove em. I know they're necessary for people who aren't as apt with computers. But to me their main purpose has always seemed to be...identifying the programs i use every day and are fairly easily identified regardless.

I use it exclusively, don't remember the last time I looked for the title bar.

I think you can drag almost anything on the header bar without activating it

I love Gnome 3. For me it's the best desktop UI because it forces you to run everything full-screen and use search and keyboard shortcuts instead. (And everything is tailored for this workflow.)

Not even joking. I wish the Windows 95 computer interaction model would just die already.

They could at the very least put labels under or next to the icons.

In regards to touch-readiness: TBH I've had a laptop with a touchscreen, and I never once used the touchscreen on it productively in any way. On a tablet it's a different story of course, but no one is forcing them to do a one-size-fits-all approach. But yeah, my main complaint is really just that stuff isn't labelled. Everything else I can begrudgingly understand somewhat

> They could at the very least put labels under or next to the icons.

On a desktop, you should be able to hover with the pointer and get tooltips. Mobile is more of a challenge, but it's not like text would be any better. You can't fit much text in the typical mobile touch target.

I shouldn't have to hover over the icon to figure out what it does. That's terrible UI. Even tiny text would be better than no text

I'm still burnt by the fact that RedHat contributes so much code to Gnome that they basically control it. They made Gnome wholly dependent on systemd and this is how RHEL was able to influence every distro out there, of consequence, to adopt systemd as well. No systemd? Then you'd have to maintain your own patched fork of Gnome.

That aside, Gnome's UI is horrendous and can only be made better by installing tons of poorly supported extensions. It's like a lesser MacOS (and frankly, i despise MacOS's desktop as well).

KDE and XFCE aren't perfect, but as far as MacOS, Gnome, Windows 8.1, 10, and further, and other Linux desktop environments, KDE and XFCE blow them out of the water. Mate, Cinnamon and others just don't have the stability or functionality.

I'm not really enthusiastic about Gnome and KDE trying to bring stuff to mobile. It's been a fool's errand. Here it is, 2022, and they never captured a chunk of the desktop market.

The phone market at one point had Ubuntu (very very briefly), FirefoxOS (even more brief), Blackberry (gone), Android (multiple versions), Windows Phone (gone), and iOS.

All that's really left is iOS and Android. Google is looking to replace Android with an OS that lacks the Linux kernel. So what you got left? Pine phones? It's even more niche and more hobbyist than desktop linux was in 2001.

The year that linux makes any serious inroads into mobile will come just like the "year of the linux desktop" came. Which is never.

So we've ruined a perfectly good desktop environment and poured countless man-hours into KDE and Gnome for mobile and to what end? Why? WHo's going to use it? What's the point? What's there to accomplish?

Beyond some college kid being real proud of his Summer of Code project, nothing of note will materialize from this.

I wonder if people who develop those apps actually use them in real life, or do they simply treat it as yet another software development job. The latter could easily explain the problem: by failing to “scratch one’s own itch”.

I moved from being a Linux zealot during the late 1990's to just use it on the server room, because what I really cared was UNIX actually and ironically all commercial UNIXes have had a better desktop story on having a full development stack story and with exception of macOS all others are practically gone.

Ironically despite all my C remarks, XFCE is one of the best experiences on desktop Linux, followed by KDE.

Just to think that on a past life I did write articles promoting Gtkmm.

The "don't theme my app" movement is really harmful to the application ecosystem.

Especially true for users with partial visual impairments, but also for other users that want to have a consistent style on their desktops or phones.

Not to mention, some people just want to theme their desktop. To make the computer feel like it's theirs.

> Please read the letter all the way to the end. This is aimed at distributions breaking apps by default, not tinkerers playing with their own setup.

https://stopthemingmy.app/

I have read through it. I just vehemently disagree that their requests are reasonable.

The only reason why people care so much for their apps' "branding" is being enforced by product management. Absent that pressure, you get a reversion to the Windows ecosystem pre-2005 (more or less), where every user can make their desktop as nice or ugly as they want, and by and large, the sky isn't falling. Because everyone works with the platform and tries to fit into it instead of breaking the mold.

One thing I really hate about electron apps (besides performance in many cases) is the extreme branding they do. Every app looks differently, not fitting in with the rest of OS.

As a user, theming is a powerful feature to make things look somewhat consistent.

Though I use KDE and Qt apps as preference, and very few gnome apps. They tend to cope with this pretty well.

As some who normally uses GNOME, I actually like apps to have distinct visual identities so that they are easy to tell apart at a glance. When using VSCode or Chromium I prefer their native title bars and modal dialogs, which integrate with the rest of their appearance, instead of the grey system-provided widgets.

I can imagine.. But everything about GNOME rubs me the wrong way, so I find it hard to compare. The huuge title bars even when I don't have a touchscreen, everything hidden under a hamburger menu, the lack of configurability..

So for me the comparison against KDE is very different. KDE's tools have pretty sane defaults and can be customised very well.

Who's “product management” in this context? Most of these apps are just made by one person.

Again, this letter isn't about users making their desktop nice or ugly; it's about distros applying stylesheets to apps without checking whether the app remains usable, and leading users to expect that this is the app developer's responsibility.

This is the most misleading part of the entire text on that website, almost as if it was written by a skilled poltician who knows how to lie on your face.

They say that they're not against tinkerers but that's exactly what they've done with libadwaita and libgranite.

Many developers think that the user's systems are their own playground or ad billboard.

They refuse to play nice around theming, user-selected icons, security sandboxes, disabling of tracking functions, providing security updates. Many are careless around the amount of memory or CPU used.

Distributions, instead, are on the side of the end users.

Distributions act as agents of the user precisely to allow you to have more options where otherwise customization would be too much effort or too technical for individual users. Taking existing applications and combining them into a cohesive experience is the entire point of having different distributions.

Gnome has a high contrast mode and UI font size options. What do custom themes add for accessibility?

Is that high contrast mode, their dark mode colors, and their font choice supposed to work for everyone?

...Changing the default fonts is definitely supported.

> ...Changing the default fonts is definitely supported.

Not for the GNOME shell, unless you're editing the relevant CSS files in /usr/share/themes or installing themes that do so. And if you do end up doing that, you get to see issues like this

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2331

And I wouldn't be surprised if changing fonts became an unsupported feature in future releases because apparently, it was just a hack and not well supported and didn't really work like themes. Apparently, gnome-tweak-tool is an unsupported tool as well.

The high-contrast mode does not accommodate for all people with colorblindness. I knew a number of people in Libera who were appalled when they updated to GNOME 40 and could no longer theme the shell to be actually visible.

Agreed. Visually, it is... fine, I don't care that much and the iconization of everything is probably just trend chasing. And personally I don't care too much about theming, but either it should be supported, or not.

But it is so dumbed-down now that I find it pointless as a desktop. I try it out every time I rebuild, and become frustrated with how it doesn't do any number of perfectly reasonable things to want from a Linux desktop. Then some random component I don't even care about starts misbehaving enough to be distracting, and I switch back to blackbox.

> Agreed. Visually, it is... fine, I don't care that much and the iconization of everything is probably just trend chasing. And personally I don't care too much about theming, but either it should be supported, or not.

I'd take inability to cope with, at the very least, color palette theming, as suggesting that a program or ecosystem probably has some serious problems with accessibility.

> and the iconization of everything is probably just trend chasing

Icons work better as touch targets due to their uniform shape. So I think the change is driven by ergonomics as well, in a context where touch support is already expected.

Touch is as relevant as 3d screens lol. I remember buying a laptop with a touchscreen back in 2011, there are as many today as there were back then. Tablet usage has dropped to less than single digits and are pretty much a dead form factor except maybe the iPad pro. Etc..

I can't stand the popup menus from a single button, like the single button in Firefox. The Gnome apps seem to have adopted it and it is horrible.

I would like a proper menubar so I know what the accelerators are without having to move from keyboard to the mouse. It's so slow.

> Also looking forward to what KDE can accomplish in this space.

https://www.youtube.com/watch?v=4DLQWv8P5Hw

That is so beautiful. As a plasma user who doesn't use many apps on android I am completely ready to make this switch.

It's cool they have this (mostly) working on mobile, but those gestures are pretty clearly all copied from Android and not a result of KDE Desktop's design decisions.

Plasma Desktop/Mobile developer here

The first version of Kirigami (the tookit used by plasma mobile) had a very interesting concept around navigation and people hated it. We still have some remnants of this with some floating buttons that are easy to reach for the thumb but also often on top of the content.

I really prefer us to copy a bit the UX of Android/iOS than spending a lot of effort trying to come up with our own UX concept that is not inferior of the one of Android/iOS. We are just an handful of developer and none is paid to work on it.

Please stick to copying the Ux. KDE desktop shines for this very reason that there is no learning curve. First versions should always be heavily inspired by something and later versions can be about innovation.

Thank you for working on KDE!

That's fine, if the Android gestures work well they can feel free to adopt them. GUI toolkits getting not-invented-here syndrome is terrible.

With UX, copying others should be the default: don't make users learn a completely new set of behaviors that aren't the ones they've been using every day.

I love Gnome's design. Maybe I'd make title bars skinnier and add corner tiling?

It's not even about likability, GNOME UI simply denies users access to functionality. Now, on a mobile, you typically don't have the time/attention/focus to actually scrutinize things much, and you need simple actions to be over-emphasized, so that kind of UI philosophy is tolerable (arguably beneficial); on the desktop it's the opposite.

My favorite thing about Gnome is that I don't have to use it. It's there so that the subsystems get used by normal people and bugs get hammered out and I can do the same thing with a small shell wrapper.

My least favourite thing about GNOME is that it has co-opted GTK and sabotaged it so that even determined developers stand no chance of achieving native look and feel on other platforms and desktop environments. The G in GTK now (de facto, not de jure) stands for GNOME.

(Expressed otherwise: I kind of have to use parts of GNOME because it has infected GTK and it’s much more difficult to avoid GTK than to avoid the rest of GNOME.)

With the advent of libadwaita, GTK really is GNOME toolkit. Most advocates are really deceptive when they talk about this and say GTK4 is agnostic to platforms but I haven't come across a single non-trivial GTK4 app that isn't based on libadwaita. Even LibreOffice is becoming a libadwaita app.

The GUI ecosystem on Linux is mostly dead. I'm trying to switch to CLI and TUI apps for all of my tasks. If they don't exist, I'll try to create them.

I don’t think libadwaita is a problem in the direction you’re saying at all—it’s a comparatively slim layer mostly of additional components that should generally not be all that difficult to make optional if you desire. And you can easily use GTK without it if you want.

Rather, I think the problem is that libadwaita hasn’t gone far enough. The advertised theory is that GTK is agnostic, and libadwaita gets you GNOME HIG stuff, but the fact of the matter is that GTK is still heavily GNOME. Their attitude to overlay scrollbars is a good example (though hardly the only one): they deliberately removed the admittedly-clumsy system-wide configurability that was present in GTK 3 (not sure if themes were able to control it before, but I think not, which was itself a regression from GTK+ 2), and have declared that overlay scrollbars are a feature of GTK 4 and there will be no attempt to comply to system conventions, or any way for users to change the behaviour; individual apps can still control it, but there will be no conventional way of switching this, which de facto means that almost no apps will provide any switch for it, and so users that want real scrollbars or want platform convention compliance are left high and dry. They also deliberately dismantled the module loading technique, which was a way of fixing things GTK made a mess of and allowing improved platform conformance support, including things like global menus (it was admittedly technically unsound, but it worked).

The issue (as I see it) is that libadwaita is GNOME's bartering chip. For years they've been anal-retentive about custom theming, be it their infinite diatribes about how XDG only needs to respect 2 themes, the "Don't Theme My App" disaster or their ongoing attempts to put custom stylesheets further and further away from the user's control. GTK4, libadwaita and Flatpak are their leverage here. Each of these systems, when taken separately, make it difficult to theme your app (though still technically possible). When incorporated though, it becomes outright unreasonable to theme things. This is wholly their fault, and this notion that "they didn't know what they were doing!" makes me roll my eyes. They know exactly what they did, and their behavior has been insanely harmful to the rest of the community.

As a matter of fact, I think the Linux desktop might just be permanently split as a result of their actions now. It's a more extreme version of the old GTK2 vs GTK3 argument, but this time the divide is more extreme. Wayland is borderline unusable on anything but GNOME. GTK4 refuses to integrate with any desktop but GNOME. libadwaita is dividing the development of applications to "GNOME app" and "not GNOME app". Flatpak is a broken olive branch that is in a comical state of neglect (and only integrates well with GNOME anyways).

This segregation has to stop, or it will kill the Linux community along with it. In their attempts to make Linux competitive with Windows and MacOS, the GNOME maintainers have completely quit listening to their users and sabotaged everything that people genuinely liked about Linux.

> The GUI ecosystem on Linux is mostly dead.

Qt says hi.

> Qt says hi.

Yeah, Qt feels better to use compared to GTK but with bugs like these

https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-...

and having to pull in hundreds of MBs of dependencies to use just one KDE app, say Gwenview, I'd say that platform agnostic GUI apps are either dead or rare. qBittorrent is a good example of such a rare app that works really well across desktop environments and window managers on Linux.

As a KDE user i have to download hundreds of MBs of dependencies just to use one GNOME app, i don't think this is a great argument either way.

> As a KDE user i have to download hundreds of MBs of dependencies just to use one GNOME app

which is why I later clarified that I think that development of apps like qBittorrent is mostly dead. They work well across all desktop environments and window managers without needing hundreds of dependencies. Everyone apparently decided to fragment the already niche desktop landscape on Linux.

Also FLTK, TCL/TK, and X toolkit.