Please don’t theme our apps
stopthemingmy.app
stopthemingmy.app
I don't know why lots of developers have chosen GNOME/GTK to build their own desktop environment (Cinnamon, Solus, PopOS etc) but at this point, it's pretty clear that GNOME/GTK developers don't care one bit about them. They want to control their apps and their ecosystem and don't want anyone telling them what to do. GNOME/GTK is heading toward Google's open source model of "look but don't touch". Anything that doesn't conform to their way is a "hack".
If Jeremy and others really want to control their own desktop environments and apps and themes, they should start searching for alternatives (Qt?) or build their own. It's a mistake to consider GNOME/GTK as a community project.
I understood that my misconceptions of GNOME was because of how it was integrated in the distros especially inconsistent theming and this letter states why it is so.
I can confidently recommend upstream GNOME confidently to someone migrating from Windows/macOS to Linux for the first time over other DE due this consistency.
One can't even change the fonts of GNOME out of the box without first installing Tweak Tool and even then, you can't change the font of GNOME Shell itself. If you dare customize the CSS to change it, you're implementing "hacks". I wouldn't be surprised if the ability to change fonts was removed from GNOME and GTK.
Not to mention that GNOME devs seem to think that volume control slider isn't required in their music app and GNOME file picker still doesn't have thumbnails. So yeah, basic features are missing.
https://jayfax.neocities.org/mediocrity/gnome-has-no-thumbna...
Then again, it's probably a useless debate at this point since everything is subjective. I'm confident that one could come up with a desktop environment with windows turned upside down and inside out with colors changing randomly every second and many people would still like it and call it "polished" and "refined".
The default apps that come with GNOME are designed to be simple and unobtrusive. They're not trying to be a Photoshop or a Final Cut Pro. If you don't like them you are of course free to install and use some other alternative, for example KDE apps should run just fine inside GNOME, and vice versa. I don't have any comments on the file chooser, anything we say is flogging a dead horse. You can search some previous discussions on reddit for all the times that's been discussed (unproductively) over the last 15 years.
I'm eagerly waiting for the day when it becomes impossible to make any sort of customisation at all in GNOME/GTK apps besides what the app developer intends. Now that user themes have been axed, I hope fonts, font size, and icons are axed as well and Adwaita, Cantarell (that's the default GNOME font right?), and GNOME Icons are enforced everywhere. It certainly won't be surprising for me if this happens and things seem to headed in this direction.
I'm sorry to see that Jeremy still hasn't figured out that GNOME/GTK isn't a community project and is still trying to engage with their devs about themes even though the recoloring API page clearly says that system themes won't be supported.
> for example KDE apps should run just fine inside GNOME, and vice versa
Yeah, I doubt that. Even if somehow it does look fine right now, I don't think it will soon.
https://gitlab.gnome.org/GNOME/gtk/-/issues/3409
> I don't have any comments on the file chooser, anything we say is flogging a dead horse.
Yeah, I know. It's pointless to have discussions, especially when the project in question isn't a community project and follows the "look but don't touch" open source model of development.
>https://gitlab.gnome.org/GNOME/gtk/-/issues/3409
I'm confused why this was posted or why it makes you think that? Apps don't need to match the theme exactly to work, I use some KDE apps with the default theme and they work fine.
>Yeah, I know. It's pointless to have discussions, especially when the project in question isn't a community project and follows the "look but don't touch" open source model of development.
If you want to discuss technical issues to solve that, I'd love to, but I am not interested in engaging you further when you make these type of false and inflammatory statements. Your time is worth a lot more than this, please don't spend it doing these things. My point is that the technical issues have already been discussed repeatedly at length, unless you are actively working on implementing this then it seems extremely unlikely that either of us will have anything new to add. So yes, in that sense it is pointless to have discussions, but it's for the opposite reason that you're saying: the community has already had these discussions and done all the "touching" that needed to be done.
It's genuinely sad to see that changing fonts is now considered a hack and unsupported behavior on Linux. I'm not into extreme customization or anything of that sort. I don't have any user themes installed besides Adwaita or any icon themes besides Breeze and Adwaita on my Linux desktop running the Sway window manager. But one of the things that I really like is not being forced to use ugly fonts like DejaVu or Segoe. It really is sad to know that soon, some apps on my system will not use the fonts I want them to.
You've asked me not to be cynical but these issues are what drive me to cynicism. I'm not a particular fan of using Linux but I still use it because I'm more uncomfortable with Windows and Mac. But if there's no difference between how they work and how my Linux desktop works, what's even the point? You can't expect users to maintain hard forks or patch and compile stuff.
Thanks for your time though.
Also, forgive me if I'm wrong about this but the entire point of Linux and open source seems to be that you can do whatever you want with it, the users don't usually need to end up patching the apps because some other distro will do it (and many of them already seem to), so usually you can find someone else who wants to support it. Also I don't think the internal setting is ever going to get removed from GTK because that it what the themes themselves use to set the font, even if libraries like libadwaita and libgranite want to enforce a certain system theme and font setting, the user still is the one that gets to override the theme.
What do you think will happen when developers who've built their apps using GTK3 start migrating their apps to GTK4? They'll most likely pick libadwaita like the developer of GTkeddit did. He wasn't aware about how libadwaita is going to enforce its own theme and was surprised when I told him about it.
Now, I know I'll never use his app because it's using libadwaita but what if apps like Firefox start using GTK4 with libadwaita? What do I do then? Switch to Chromium? It uses GTK as well. The so-called choice that open source offers is merely an illusion in some cases.
The choices that GNOME devs make end up hurting users like me who want nothing do with GNOME and who aren't even using GNOME.
But that also leads to another point: libadwaita is intended to be a library that implements the GNOME HIG. If you are using libadwaita apps, that means you are using an app that is intended for GNOME -- so if you "want nothing to do with GNOME" then I don't understand why you would be intentionally using their apps and then complaining that they don't act right with a non-GNOME desktop. A developer who chooses to use that is intentionally choosing to go with the GNOME platform, and there is no reason to be upset about that -- it's not a decision that you have to worry about if you just want to ignore GNOME apps.
Also I think you have a misunderstanding of how Firefox is built, they are a cross platform app, they are not going to use libadwaita. They already have their own theme system too and have for quite some time: https://addons.mozilla.org/en-US/firefox/themes/
I would advise to do more research before making assumptions about these things, if you have questions you'd like to ask then those are a better way to start rather than jumping to the worst possible conclusion. Please try to be careful about online misinformation.
Haven't Clasen and several other devs on the issue tracker you and I linked above clearly has statements like "linking to libadwaita is an explicit decision to use the Adwaita theme" and "core GNOME applications linking to libadwaita will then thereby require that every distribution shipping GNOME is forced to consent to having Adwaita as the theme".
The only way a user's own custom theme will be used if a proposed opt-in flag is added to libadwaita (doesn't seem like it will be, recoloring API is being favored) and app developers use that flag.
Correct me if I'm wrong in this point and I'd be happy to go back and talk to the GTkeddit developer again but from what he independently tested, he seems to have reached the same result as I think.
Yes, linking to Adwaita is a decision to use Adwaita theme by default, because the widgets in it are intentionally designed to work well with only with those specific colors, spacings, fonts, etc. But the app developer can override that afterwards if they have additional CSS.
>every distribution shipping GNOME is forced to consent to having Adwaita as the theme
Can you show where this quote came from? This makes no sense and I do not understand why someone would say this at all, any distribution shipping GNOME is free to modify the Adwaita theme or ship another theme, as Ubuntu is already doing for some time. GNOME developers may grumble about it and write more letters like this but they cannot stop them from doing that, no one is "forced to consent" to anything as this is all open source code. If you notice from the letter, the concern is actually the opposite, it's about about downstream forcing their untested themes on some GNOME apps without concern for the app developer, which is resulting in bugs and unhappy users.
>The only way a user's own custom theme will be used if a proposed opt-in flag is added to libadwaita
No, this is incorrect. The opt-in flag is about the platform theme. The change in libadwaita does not affect the user's theme. User's theme still has top priority over all other CSS, this is documented: https://docs.gtk.org/gtk4/class.CssProvider.html
And you can in fact verify that it works if you have the latest libadwaita from git master.
I would like to again emphasize that even if this weren't the case, the code is open source and it would still be quite trivial to comment out some lines and install your own CSS, and that is the worst case scenario. So realistically there is little reason for alarm.
https://files.catbox.moe/p5f920.png
https://gitlab.gnome.org/GNOME/libadwaita/-/issues/259#note_...
I was mistaken to think this quote came from a GNOME dev but then again, a GNOME dev (Benjamin Otte) does seems to have agreed with this so I guess it's all the same.
> So realistically there is little reason for alarm.
I hope you're right and that my fears are a misunderstanding. I have basically started removing any software that has anything to do with GNOME, including Flatpak and Flatseal, which I was happily using until now, because there's no telling what kind of control will be taken away from me. Again, I hope I'm wrong and this is all a misunderstanding on my end as you're saying.
I don't understand why you would start reactively uninstalling apps or control would be taken away, I don't believe any of them have gone closed source. If the app is open source then no control can be taken away from you, you can just grab the source and inject your CSS. Again would be happy to walk you through this process, but that would be in the worst case scenario, right now and for the foreseeable future it's unnecessary as you can still use the method I previously described with setting your user theme.
It also doesn't really make sense to me to uninstall some app because of some theoretical bad thing that could happen in the future, if you take that view then you would have to uninstall everything it seems, because there is always a possibility that developers make some decision you don't like 10 years from now when the computing landscape has changed. You can of course stay on an old version if there are some changes you don't like, the developers might grumble more and tell you to upgrade for usability and security reasons, but that's a decision you make according to your own risk factors.
>Flatpak
Huh? Flatpak is an API and CLI, it doesn't use GTK. The ways it's usually accessed through a GUI are GNOME Software and KDE Discover, but you don't have to use those.
In hindsight, I was perhaps being reactive and might've acted irrationally but I still believe that I should try to stay away from anything related to GNOME or GTK, if possible, simply because I don't trust GNOME/GTK developers to keep their "every preference has a cost" philosophy limited to GNOME itself. Like this, for example.
https://gitlab.gnome.org/GNOME/gtk/-/issues/3787
If I'm being polite, pretty interesting comments from Clasen. Subpixel Positioning might make sense on HiDPI displays but most people still don't have them.
Yes, that philosophy makes sense in some kind of apps but it isn't one should follow universally, in my opinion.
Another simple example is GNOME Screenshot and Spectacle. Spectacle, in my opinion, is perhaps the best screenshot tool on Linux because it offers sensible and basic annotation tools. This is what Android does using its Markup tool on Android and Windows with its Snipping Tool. I suspect Mac has a similar offering. If I want to share a screenshot with some personal information redacted, there's no way to do that using GNOME Screenshot. Yes, I know I can find another app for doing that but that's not the point. It's the "every preference has a cost" philosophy in play again which makes some things dumbed down and deprived of sensible features when they shouldn't be.
I am by no means a KDE "fan" though. I ended up uninstalling KDE fairly quickly when I tried it a few months ago.
I also stand by my statement of "GNOME not really being a community project" after reading the blog posts by Tobias. There is little room for disagreement besides what the "GNOME way" says and little care for downstream.
Thanks for your time though. I appreciate how you've been patiently replying to my comments. Most people I talk to in FOSS communities generally aren't even receptive to discussions when its about disagreement. Everything is either the user's fault or his hardware is faulty.
That isn't a philosophy, it's just how development works. Preferences do have a cost, in any project. The actual GNOME philosophy is more along the lines of "GNOME would rather spend the cost of preferences elsewhere" which has been part of the project's philosophy for many years, if you disagree with that decision then feel free to use some other platform.
I don't see what your issue is with GNOME Screenshot, you don't have to use it. Just use Spectacle, nobody is going to take issue with you doing that. The builtin GNOME tools are designed to be simple and straightforward, not to include every feature under the sun. Which features an app has is entirely up to its developer, you can say they should or shouldn't do something but it's not your decision to make unless you are developing that app. The developer might listen to community suggestions but they don't have to, and they are very unlikely to if the suggestions are rude.
>I also stand by my statement of "GNOME not really being a community project" after reading the blog posts by Tobias. There is little room for disagreement besides what the "GNOME way" says and little care for downstream.
This paragraph doesn't make sense to me. The "GNOME way" is just what a group of loosely connected developers all agree on and those blog posts are just one developer's opinion. You're saying it's not a community project but that "GNOME way" is entirely the product of that community, there is nothing else there. Downstream is only relevant as far as they contribute back upstream, because there is no other possible way for there to be any relationship there.
But I would say in a lot of cases with FOSS communities, the well has been poisoned and interactions become toxic very fast, I just try to cut that behavior off at the head and correct any misinformation that is out there.
Because the licensing status of Qt was for a long time somehow murky [1]. By 2000 when it was GPL'd many now-current desktop environments have already been born.
[1]: https://en.wikipedia.org/wiki/Qt_(software)#History_of_Qt
>It's a mistake to consider GNOME/GTK as a community project.
You're getting this wrong -- GNOME is very much a community project, but it's one that happens to be heavily driven by designers. Maybe this is unusual for an open source project? The general point with the request is that you can't just try to make a desktop that re-uses some GNOME components while also throwing out everything their designers did, the end result there is that users have a bad time. This is not about making someone conform to anyone's way, this is about distros working with app developers to provide the best possible experience for users. Switching toolkits is not really going to fix anything here, you will run into the same issues with any other toolkit if you try to restyle apps in ways that were unsupported and unintended by the app developer.
Please don't dismiss my statements as baseless. The presence of an issue does not imply progress. Jeremy is asking for a theming API or a method to let apps use a different theme besides Adwaita.
> Jeremy: I'm curious if you think there is a best way to have GNOME core apps continue to use our own theme.
> Clasen: If you ask me, the answer is no. To the best of my understanding, linking to libadwaita is an explicit decision to use the Adwaita theme.
I don't think there's any confusion or baseless assumption on my end.
> You're getting this wrong -- GNOME is very much a community project
Doesn't look like a community project to me, not in the least. It's as much a community project as Android (AOSP) is.
> This is not about making someone conform to anyone's way, this is about distros working with app developers to provide the best possible experience for users.
And GNOME/GTK devs get to decide what's the best possible experience for the user — removing any customization possibilities for the sake of consistency. If anyone doesn't like that, they can piss off. This is pretty much what "making someone conform to someone's way" looks like.
I don't understand why you are talking about Android and/or Google, there is no GNOME Inc. that is directing development. If you want to know more about how the GNOME community is structured, please consider starting by reading this blog series: https://blogs.gnome.org/tbernard/2021/06/11/community-power-...
>And GNOME/GTK devs get to decide what's the best possible experience for the user — removing any customization possibilities for the sake of consistency. If anyone doesn't like that, they can piss off. This is pretty much what "making someone conform to someone's way" looks like.
Please don't take such a cynical view, if you look at things that way then using anyone else's code would be "conforming to their way" because ultimately that's what it is isn't it? Someone else decides the best way to write that code and then you use what they wrote. Since I don't think you wrote all your software yourself from scratch, there is obviously some level of compromise there that you already acknowledge, so what is the real issue you're having? And I don't mean something vague like "my theme broke" I mean how does it relate to the end goal of what you're trying to change these programs to do?
Discussing what makes themes difficult to support - how to design themes that don't break good apps, and how to design apps that don't break with good themes - would be far more productive than telling people not to use a core feature of their desktop.
I don't know where you heard this, but to my knowledge this hasn't been true. GNOME 3 didn't really support "themes" proper, for a while now the only supported theme is Adwaita. It technically did support re-styling with CSS, and you could load a different CSS using the tweak tool, but this was always considered unsupported -- if you loaded a theme that had bad color contrast or makes the text otherwise unreadable or broke any number of other things that a theme could break, then that was on you. The option was appropriately hidden in the tweak tool so non-technical users wouldn't accidentally load a theme that breaks their desktop in an unrecoverable way.
>Discussing what makes themes difficult to support - how to design themes that don't break good apps, and how to design apps that don't break with good themes - would be far more productive
Respectfully, it wouldn't. This has already been discussed quite a bit and the problem is that if you want the full power of CSS theming then the apps will always break, because the theme can literally change anything anywhere. There is no way to design a theme or app that works correctly here, it's like trying to take a random CSS file from one website and then applying it to another random website. Sure maybe it might change some things, but most likely it won't really work because none of the class names will match up. The only way "theming" really can be done reliably is to do it in small controlled ways, e.g. I believe there is some discussion of allowing changes to the accent color similar to what Windows and Mac do.
Distros do this because it looks good in screenshots and give the system a unique flare, but it gives all these applications a bad image when people try them and they look terrible.
Is the expectation that programs like geary should look at all popular distros and make style sheets to look good in all custom themes? I think they are saying they don't have time. People are stepping on their hard work and giving their apps a bad name.
and even if they were designed to be themeable, that doesn't address many of the other concerns here - designing an app to be themeable doesn't automatically update the documentation with whatever custom themes get applied, or ensure that the icons you've chosen in your theme make sense in the context of the app. "apps should be themeable" seems to be the point of this manifesto - the app developers could just block themeing entirely if they wanted to. they don't want to do that, they seem to just be asking that if a distro wants to apply a theme to an app, then that distro should be the ones doing the QA to make sure the app still functions as intended with the custom theme, and that documentation is still available for users who experience the themed version of the app.
App looks like crap? Untheme it and file a bug if it still looks like crap.
Icons don't make sense? Untheme. Looks more sensible now?
A one off patch to GTK (other toolkits are available) and this problem has a solution.
The objection here is that distributions are building incompatible system themes that break standard GNOME expectations and make applications more confusing for users.
They're not talking about individuals messing with their systems.
So no, it wasn't web; the dominating desktop OS always lacked the UI consistency.
So the phenomenon really started with Microsoft themselves. Sure, the more muted dialog backgrounds and vibrant foreground elements introduced since XP look far better than the Win95-esque greys, but I’m sure people who created their own themes (probably due to disability like color blindness) like their colors better than Microsoft’s.
please be careful clicking this link from HN. He doesn't like the HN crowd very much.
I understand the app developers, if you have to support end users because unexpected changes were made not even by the users themselves, it makes writing applications painful.
> If you like to tinker with your own system, that’s fine with us. you should be aware that you’re in unsupported territory. Any issues you encounter should be reported to the theme developer, not the app developer.
But this is beside the point: what drew me to Linux in the first place was that it empowered people to remix all the aspects and encouraged people to share these remixes (or “rices” as they’re called on r/unixporn: https://www.reddit.com/r/unixporn/comments/pfue6h/gnome_2_fo... )
Also, I would suggest avoiding the use of that term as it comes from a racial slur aimed at Asians: https://en.wikipedia.org/wiki/Rice_burner
Otherwise, I very much prefer when apps pick the system theme; on my desktop, both GTK and Qt apps look more or less the same, and I find this good from both aesthetic and ergonomic points of view.
That said, I absolutely agree when (if) it comes to theming actually breaking functionality (and the original developer having increased support burden because of it).
But asking distros not to style icons feels a step too far, in particular app icons. I appreciate when a distro tries to achieve visual consistency.
Just say "Our apps aren't designed to work with themes. Take this into consideration when you distribute or use a distributed theme". Yeah it's more passive. But with the former, you're starting fights with people for no reason. You don't care when users theme your app, you care when they download a themed version and complain to you when it's broken.
And users too, need to stop rudely complaining when a free and open-source app doesn't support some theme. They don't have any obligation to do anything. People being rude to OSS maintainers drives them to leave open-source and avoid features (like themes).
Theming ("branding", as they refer to) is, in a sense, just the core of their marketing campaign.
This is not just ideology - they do try also in practical ways to prevent third party devs from customization.
For a background of how horrible the people involved are, you can start from https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotti....
Here's the antisocial answer of one of the GNOME devs:
>> mccann replies:
> 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.
Some of them have too high contrast which makes me see after effects of text everywhere on the screen. Some of them have poor contrast and require users to ruin their eyes. But no, let's assume everyone on Earth is fine with a single light and a single dark theme.
Also,
> We believe that a technical solution would likely not be effective, because this is not a technical problem.
That's another manhole we developers tend to fall into. Props for avoiding it.
Needless to say, I do agree with the letter's appeal.
A conversation about the expectations and burdens that people take on when volunteering their time to develop open source software is beneficial to everyone, and at the very least it is worth understanding their point of view. Maybe some solution results from speaking up. Maybe not, but at least they tried to engage with people before giving up.
Pretty sure this includes the article, too. ;)
>This is aimed at distributions breaking apps by default, not tinkerers playing with their own setup.
And further down:
>If you like to tinker with your own system, that’s fine with us.
Sources? Win9x and 2000 were perfectly restyleable as far as I know.
This essay comes from the position of "the application developer should not be expected to make the application restyleable", which hangs on the above assertion. If the assertion is false, the argument falls apart, amounting to nothing more than pleading to change the social expectations.