Please don’t theme our apps(stopthemingmy.app)
stopthemingmy.app
Please don’t theme our apps
https://stopthemingmy.app/
79 comments
Please don't jump to these baseless conclusions based on a misinterpretation of one twitter post. The issue here is with libadwaita, not with GTK, and if you actually read the gitlab issue chain by that person then you will see that progress is being made: https://gitlab.gnome.org/GNOME/libadwaita/-/issues/259
>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.
>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 jump to these baseless conclusions based on a misinterpretation of one twitter post. The issue here is with libadwaita, not with GTK, and if you actually read the gitlab issue chain by that person then you will see that progress is being made: https://gitlab.gnome.org/GNOME/libadwaita/-/issues/259
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.
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'm sorry, but this is still all based on a misunderstanding. Even without this change, apps still have the ability to use a different theme besides adwaita, and with the change it's still a thing that they have to opt-in to. Asking for a theming API will not change the reality of this, and in fact the discussion there is still all centered around things that are still opt-in for app developers. They get the final say when it comes to their own apps, and if they decide they are going to hard code in adwaita (or some other theme) or use some toolkit that doesn't support themes then then that's the way it is. I would advise not putting so much weight on non-technical rants from twitter, and instead I suggesting focusing on finding ways to help app developers deliver you the best apps that they can.
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?
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?
Hasn't that always been the trade-off of GNOME over KDE? GNOME is very much the "we know what's right for you" desktop environment for Linux, KDE is the "customize ALL the things" desktop environment.
I recently switched from KDE to Upstream GNOME because I was tired of long pending bugs(e.g. Dolphin/Baloo going rogue) while new features keep getting added. I was surprised to find how refined GNOME is, everything just works.
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.
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.
It would obviously be easier for GNOME to ship an apparently more refined experience when customization possibilities are negligible and basic features are missing.
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".
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".
In some situations, changing the font could absolutely considered a hack -- this can break apps in subtle ways by messing with the spacing and sizing of elements, and it gets worse if you designed your app for some specific form factor(s). It's perfectly reasonable for an app developer to say they only support certain fonts. I'm sorry if that's disappointing to hear, but every app developer cannot be expected to test their apps with every single font in existence that someone wants to use.
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.
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.
> In some situations, changing the font could absolutely considered a hack
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.
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.
That has basically already happened on Windows and Mac and for good reason, so it's actually long overdue to happen on Linux. Apps simply cannot be expected to work with an endlessly growing matrix of user customizations. At some point people have to decide if they are going to prioritize on working on new features, or if they want to prioritize allowing people to change the colors and the fonts in ways that could potentially cause bad breakage. Your stance on the subject might be different from others. Since it's all open source, you can of course patch it and modify it all you want to match your priorities, and the developers have no problem with you doing that (and may even encourage it sometimes).
>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.
>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.
> That has basically already happened on Windows and Mac and for good reason, so it's actually long overdue to happen on Linux. Apps simply cannot be expected to work with an endlessly growing matrix of user customizations.
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.
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.
This is not new, GNOME has hidden the font settings as an undocumented setting in the tweak tool for quite some time now. I don't think you should have to be disappointed that it's considered an unsupported hack, if it works for you, that's great, keep on doing it. All "unsupported" means is that the developers don't test with that setup... and how could they? They can't possibly test with every font there is, so marking it unsupported is really only an acknowledgement of the way it already was before. If an app developer says don't theme my app, that's likely because it has a high probability of breaking the app. That's what the letter is talking about and gives examples for. And yes, font changes can break apps.
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.
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.
> 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.
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.
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.
I don't understand why you're saying that hurts you, that doesn't make sense. If that developer wanted to add support for themes on top of libadwaita they could easily do that, GNOME is not preventing anyone from doing that. Also, what you have told the GTkeddit developer was very likely not correct, users can still load their own theme and libadwaita will not override that. The libadwaita change is about the platform theme, not the user's theme, the user theme still has top priority. I would suggest to correct your statement to that developer before they make an uninformed decision.
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.
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.
> Also, what you have told the GTkeddit developer was very likely not correct, users can still load their own theme and libadwaita will not override that. The libadwaita change is about the platform theme, not the user's theme, the user theme still has top priority.
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.
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.
>linking to libadwaita is an explicit decision to use the Adwaita theme
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.
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.
> why lots of developers have chosen GNOME/GTK to build their own desktop environment
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
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
There also aren't any Qt bindings for C, to my knowledge.
Gnome and GTK are designed with themes as a core feature, and have been for ages. This is like refusing to support application menus (vs window menus) when they became a core part of Gnome. I personally may not use them, but it is part of the system UI guidelines, and if I want my app to integrate with the rest of the system, I need to support it.
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.
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.
>Gnome and GTK are designed with themes as a core feature, and have been for ages.
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.
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.
When I used to write apps for Gnome I would always test with all the available style sheets. Why would you test with just one? At least try an inverted (dark) and a low contrast style.
I think it's been suggested for a while to test with the default themes (Adwaita, Adwaita dark, High Contrast) but everything else is unsupported. I don't see how you could test with every stylesheet available when a search seems to turn up over 1000 of them out there: https://www.gnome-look.org/browse?cat=135
The gtk debugger even has a convenient dropdown to change the theme on-the-fly.
Telling me not to change my own icons is truly a bridge too far.
>If you like to tinker with your own system, that’s fine with us.
> If you like to tinker with your own system, that’s fine with us. However, if you change things like stylesheets and icons, 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.
Yeah I changed my Firefox icon to go away from the POS it became, I'm totally going to blame any Firefox bugs on my icon. This page is ridiculous.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Pretty sure this includes the article, too. ;)
Pretty sure this includes the article, too. ;)
Debian had a really good solution to this problem -- they just called Firefox "Iceweasel". I don't even remember what they were mad about but it makes me giggle every time it shows up.
Mozilla didn't release the Firefox branding under the same license as the rest of Firefox (and, iirc, the branding license was non-free per the DFSG). So, Debian forked Firefox, Thunderbird and a couple other things and replaced all the branding with the Ice* names and icons. Mozilla eventually gave up and so Debian now distributes Firefox with the Firefox name and branding.
If all you are doing is changing your own icons the letter doesn't apply to you, as it clearly states multiple times.
They explicitly say they're not asking that. At the very top:
>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.
>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.
This is the antithesis of open source and the things that drew me to Linux in the 90s and 00s
Exactly. WTF? If I release an open source app I would LOVE for you to theme it, mod it to your heart's content, and have a party. Send me a pull request if you come up with something cool looking.
>This is aimed at distributions breaking apps by default, not tinkerers playing with their own setup.
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.
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.
If I pick eOS because I like its look and feel, I sure hope eOS attempts to make that look and feel as consistent across apps as possible.
Then eOS should be fielding look-and-feel bugs for the stuff that they changed, shouldn't they?
Sure, and my experience is that most distros do.
To expand: the web gave us a mindset where developers and designers dictate to everyone else how their app will look. Beforehand, that was up to the OS, the windowing system and/or the user. Now, it’s fair to ask that problems with appearances be reported to the intermediate themers first, but this invasion of the web mindset is profoundly anti-user and anti-community.
It wasn't even really until the modern web that this happened; the browser is called the User Agent because it's acting on behalf of the user, not the website. CSS Zen Garden showed what you could do just by changing CSS. Even today though you can still do what you want to a lot of sites, from adblocking, to restyling with things like Stylus, or full custom JS with Greasemonkey/Tampermonkey. It's the OS apps that are less customizable, but I don't want them to become even less so.
Was it, really? When Microsoft implemented arbitrary shapes for windows, Windows apps started to come in all shapes, sizes, and with custom theming engines. Music players were particularly prone to this - not even talking about apps like Sonique, but Microsoft's very own Windows Media Player was like that.
So no, it wasn't web; the dominating desktop OS always lacked the UI consistency.
So no, it wasn't web; the dominating desktop OS always lacked the UI consistency.
Adding onto your point, I’m reminded of the video “Chain of Fools”, where a machine is upgraded from Windows 1.0 all the way through to Windows 8. Once he reaches XP, the theme he configured back in one of the first Windows versions just disappears and gets overridden with XP’s defaults. Then it happens again and again for every version since then, despite the guy changing the theme back to his custom one before each upgrade.
https://youtu.be/vPnehDhGa14
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.
https://youtu.be/vPnehDhGa14
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.
[deleted]
[deleted]
Well this is the dumbest thing I've read. If I needed confirmation to stay on Plasma, this is it.
Plasma looked good but it didn't handle suspend very well :( So I had to go back to Cinnamon.
Dark Reader for Firefox themed that very website as I read it, teehee
I think these apps still have a long way to go in terms of aesthetics.
> apps can be arbitrarily restyled without manual work, which is and has always been an illusion
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.
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.
Sure - as long as you provide dark/night mode.
Ah, the one size fits all approach. I guess the user better find a different app if he doesn't like the default themes. Lots of light and dark themes are sloppy and poorly designed.
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.
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.
Your words not mine - I'm just saying that I'll take an imperfect dark theme compared to the white/bright background that apps usually provide.
The article says clearly they are talking about distros that apply system wide themes without checking that all GTK applications still look good and not taking about people tinkering.
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.
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.
Apps should be designed with the goal of being themeable. Applications need to supply hints and avoid e.g. icons with baked in BG.
apps are designed with many goals, and have to make compromises on where they put their efforts. i'm sure they would all love to have the resources to devote to theming, but it's not realistict to expect apps to prioritize theme support over core functionality.
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.
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.
There’s a sort of antagonism between users, distro developers and app developers these days in the Linux community that’s a bit sad to see.
An option here would be to have a new item in the top left menu (by default, your theme may move or even remove this) on the window: Untheme
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.
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.
Honestly wish GNOME would leave well enough alone. The best UI is the one I don't have to maintain a configuration that fixes all their mistakes over the years. And it's complicated too, because they've got multiple places where things need to be configured back to a reasonable interface that doesn't hide controls or shadow common keybindings that have existed for decades.
I see their point. If they don't want their apps to pick up the system theme, I'd suggest that they provided a choice which theme to use, and bundled a good default theme, or several. For instance, GIMP and Inkscape do this, which I find very nice. GTK makes this easy to do.
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.
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.
I don't use themes or a very heavily themed distro, so maybe I haven't seen egregious (mis)uses of theming.
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.
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.
I don't know why people are against this, it seems reasonable to me. If anyone goes beyond the intended usage (through themes or other modifications) then the developer shouldn't be resposible for supporting it
It's because the GNOME devs (which, I think, includes the GTK ones) have an extremely protective position towards "their" product, which clashes with the open source spirit.
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.
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.
I'm not sure why you're saying that's antisocial, it was completely true then and it's still somewhat true now. GNOME, Ubuntu and XFCE all have their own subtle differences, if you want to have a good experience for any one of them you'll have to target that specific desktop and test for it. Placing the blame for this solely on GNOME doesn't make any sense, when each of those groups all have their own product that they're trying to promote.
But this isn't an instance of the GNOME or GTK devs complaining. It's an independent person making applications for the platform. If the GNOME devs are against people doing things with their code then it's a whole different issue to this one.
I'll add it to the list of reasons why Linux desktops have a long way to go before becoming mainstream. Brings back memories of jwz. https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop...
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.
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.
Which other mainstream operating systems allow to apply global themes?
Windows, up until at least XP, had deep support for restyling.
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... )
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... )
You can still do that, but hopefully you understand that by doing so, you are in unsupported territory.
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
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
I didn’t realize that latter part, sorry
No biggie, I've seen lots of people in car modding communities who use that term casually and don't know where it came from or why an Asian person would find it rude, so I just try to educate people :)
What an absolutely wild opinion to hold! Kind of speechless at the hubris, especially in this context.
The authors took care to carefully express their intentions, wishes, and argument. I find it disappointing to see many comments like this that want to injure more than discuss.
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.
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.
Why is everyone on the internet so argumentative (ironic i know)?
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).
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).
What an excellent piece of writing. Written communication is darned hard, especially with an audience you don't know. Apparently I'm already so used to bad writing that this letter jumped out to me for the quality of its writing alone. Something like this takes several iterations of work, not just inspiration and good luck. I can only commend the authors for putting it in.
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.
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.
I absolutely hate this. I want my apps to look and act uniformly. If you want a square you can paint anything into without a regard for the system you’re no better than an Electron dev.
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.