Completely antithetical to free software. If I want to modify your code or the environment it runs in, I will.
Gnome is not an OS or a "platform", it is free (as in freedom!) software to be used and tied together however the users, distro authors, ansd whoever else feels like.
Writing and publishing open source software then trying to guilt trip people into interacting with it at arms length and subject to condiions like closed source, proprietary software is nuts.
I honestly couldn't care less if all these people quit writing software tomorrow, if the alternative is this nonsense.
Did you actually read the article you're ranting about? They repeatedly and specifically say they have no problem with users applying theming to applications, as long as they report issues to the theme developer, and not to upstream. Their actual ask is for distros is to stop applying theming by default, which is entirely reasonable and sensible to me: you more or less guarantee that some apps will arrive out of the box in a broken state, and people will not realize that it's not the fault of the application developer.
The issue of distros breaking applications and giving upstream developers unnecessary headaches and noise because of it is one that goes way beyond themes. Recall jwz's ugly fights with Debian about the Xscreensaver warning. There's not a perfect solution, but distros can at least try and not make the problem worse for the sake of "brand identity", which is what this article is actually complaining about.
> There's not a perfect solution, but distros can at least try and not make the problem worse for the sake of "brand identity", which is what this article is actually complaining about.
Erm, the page literally argues in favour of "brand identity" (only for themselves, of course!)
> Their actual ask is for distros is to stop applying theming by default
Which is exactly what the person you are replying to is highlighting. See freedom 3 here[0].
> There's not a perfect solution, but distros can at least try and not make the problem worse for the sake of "brand identity"
This website is explicitly (!) about valuing the "brand identity" of applications over that of distributions. Both are equally unimportant. Write software. Distribute software. Change software. Distribute changed software. Do it all.
While I agree that users shouldn't be reporting breakage caused by distro maintainers, those maintainers have the right to modify and distribute changes in accordance to the license. There are also many instances where these changes will be better aligned with the desires of end users. It is not simply a matter of the distros brand identity.
> those maintainers have the right to modify and distribute changes in accordance to the license.
Sure, but this is a "just because you can, doesn't mean you should" situation. The authors of this blog post are asking distro maintainers to not do it, and IMO giving good reasons.
> While I agree that users shouldn't be reporting breakage caused by distro maintainers,
One of the reasons I brought up the jwz-vs-Debian Xscreensaver kerfuffle from a few years ago is because it was a great example of how it's not sufficient to just wave your hands and say "well, users should be filing bugs against the distro, not against upstream." Yes, they should, but empirically they don't and they probably never will.
We need to figure out a solution for the real world as it exists, where upstream maintainers have to waste time and energy on bug reports that have nothing to do with them. OSS maintenance is enough of a headache as it is with real bugs that are actually your fault. It feels both against the spirit of OSS, and just plain unsustainable, to pile onto volunteers the hassle of dealing with users who are angry at a change their distro made.
Yes, but there’s obviously more to the story: this whole problem exists because there’s no real theme support at all. So users and distros literally hack css up and it usually ends up looking okay for the popular apps and terrible for all the others. There’s got to be a middle ground where some window manager provides more structured guardrails for people to apply custom styles and themes to their system that don’t break app layouts and make them look like crap. That way users and developers can meet in “supported” territory. The inability to effectively style Linux is one of the reasons I lean back on macOS so much.
The brand complaint is BS though. Using an alternative app icon does not rob you of your brand. If you care about your brand so much then defend it in your license. And don’t come whining if that means some popular distro won’t package you.
The article isn't saying what you think it is saying. Despite the clickbaity opening, this isn't calling for users to stop adjusting the appearance of apps.
This is about distributors applying system wide default theming to apps without doing any QA and then users being confused when the app doesn't work and doesn't match support documentation. Then these users file bug reports with the app developer rather than with the theme creator.
The letter is asking for specific changes so that the app developers don't need to take away user's ability to theme apps by hard coding a stylesheet (since that is the only way to disable automatic distro themes.)
> 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.
> If you are a distribution who changes the system stylesheet and icons, please reconsider this decision. Changing third-party apps without any QA is reckless, and would be unacceptable on any other platform. Your actions are hurting us app developers a great deal, and are damaging to the entire ecosystem beyond your distribution.
That's a fair point, but in terms of the right to use and modify free software there's no difference between an end user and a distro creator.
What if a user themes their apps a bit and publishes their configs?
What if that turns into a distro or a "spin" on another distro with a website?
What about things like Regolith [1]?
It's a scale not a yes/no question IMO, and these devs are showing hostility to some users, which comes across as an attitude of arrogance and hostility to all users.
> terms of the right to use and modify free software there's no difference between an end user and a distro creator.
Yes, but completely irrelevant as this is not asking for the right to be taken away.
> What if a user themes their apps a bit and publishes their configs?
Totally fine. Publishing those configs allows users to have a choice and opt in to a config that they know was not QA'd by the developer.
> What if that turns into a distro or a "spin" on another distro with a website?
If the distro takes on the role of providing QA, documentation and support then there is no issue. The distro could also clearly communicate about the theming so users know why stuff might break. The issue arises when they do none of these things and make the resulting breakage someone else's problem.
> It's a scale not a yes/no question IMO, and these devs are showing hostility to some users, which comes across as an attitude of arrogance and hostility to all users.
I don't see any hostility. I see a very politely worded request that explains the negative impacts certain behaviors have in certain context.
I don't know anything about regolith but if you are a distro that does theming, then you should do the QA yourself. Yes, that means you have to check every single package every single time it gets updated.
When I think about the scale of the problem I get the impression that only a commercial company that earns money would have the resources to do this. There is no way in hell you can get enough volunteers to do this in a reliable way.
> This is about distributors applying system wide default theming to apps without doing any QA and then users being confused when the app doesn't work and doesn't match support documentation. Then these users file bug reports with the app developer rather than with the theme creator.
If the support documentation only applies for certain themes, then that sure sounds like a bug in the application (or at least its docs)!
Likewise, if such requests are a consistent drain on resources (e.g. white text on white background for some custom widget, or whatever) then that also sounds like a noteworthy bug: either in the application (what's it doing wrong compared to unaffected applications that the theme developer tested against?); or the toolkit (why is GTK3+ so fragile in the first place?).
Looking at the list of signatories, it seems many of them are applications which embed a giant WebKit frame and cross their fingers (e.g. I use Geary on my Pinephone, which spawns a WebKit process with 100GB virtual RAM; even though I've set the plaintext-only preference!). That could also be the cause of such issues. Or indeed the fault might rest with GTK, for not providing the required functionality, which drove those devs to embed a browser engine instead.
That's a false dichotomy. This is the old, "I disapprove of what you say, but I will defend to the death your right to say it." It's possible to both believe people should have the right to do something annoying, and simultaneously wish they wouldn't.
The function of the operating system is to create an environment in which other applications can be run. Themeing running over-top of an application's UI and breaking it is not acceptable IMO. As someone who uses computers, if I discovered my operating system was rendering software unusable in an attempt to make it look a certain way, I'd be furious.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
I think you were already in unsupported territory.
And yet, open source software lives and dies on support. Projects that are perceived as having unresponsive upstreams that don't support the project are often in a death spiral.
I think what they mean by supported though is (in a very simple example) if you complain about a missing button but it's because your DE theme washes it out then they aren't going to help, otherwise they'd look at the issue and try to resolve it. I think this is reasonable. Sure there's no awareness, consideration, capacity and all that but a reasonable attempt at support.
I think "unsupported" here clearly does not mean a legal obligation to support, but rather "support" in the sense that in the free software community, it is convention for developers to provide help to (nonpaying) users, and that convention should not apply if users make certain changes to the software.
It's a distinction without a difference. If they are unwilling to support the platform then why use the platform.
At that point they are the ones abusing the OS environment to gain benefits without contributing back to the community. And it becomes hypocritical to say "you can't do what im doing"
Sure, and if they just said "we'll close tickets for anything to do with theming" or similar, it'd be fine, but instead we get:
> We understand the need for distributions to stand out. However, we urge you to find ways to do this without taking away our agency. We are tired of having to do extra work for setups we never intended to support, just to have that used against us when people tell us the breakage from theming is “not that bad”. You are not doing this to Blender, Atom, Telegram, or other third party apps. Just because our apps use GTK that does not mean we’re ok with them being changed from under us.
> Since you are shipping the GNOME platform, we assume you want this ecosystem to be healthy. If you do, we ask that you please stop theming our apps.
I'm sorry but just becuase you make some software that works together you don't get to designate it a platform and decide you should control it. Not in the free software world, at least.
Debian et al. aren't "shipping the Gnome platform", they're shipping package managers that can install many things including a bunch of Gnome software (and vastly more non-Gnome software). A very large proporrion of it can be themed or customised in some way.
Some people use Gnome "stock" but don't install or use any of the Gnome apps, others use aspects of the Gnome WM but without the default panels and interfaces, others install the whole lot, some run Gnome software but with a totally different WM or desktop environment, and then there are things like Regolith [1] which use some Gnome software but are pretty unrecognisable compared to a default Gnome install.
Gnome devs are just writing software. Their desire to deifne and own and control a platform is their problem, not ours.
> if they just said "we'll close tickets for anything to do with theming" or similar, it'd be fine
Honestly, this is probably the best approach. It puts the onus back on the person making the modifications for things that they know and understand that are fundamentally trivial in nature.
> I'm sorry but just becuase you make some software that works together you don't get to designate it a platform and decide you should control it.
I don't see anything about this post as an attempt to exert control. I think it's pretty reasonable to ask that users don't theme their apps with the implication that if they do they're not going to get any support. But to your point they should probably just come right out and say that.
> Completely antithetical to free software. If I want to modify your code or the environment it runs in, I will.
It's fine to politely ask not to modify code in certain ways. It's only antithetical to free software to take away your right or ability to modify it however you want.
I have some conflicted feelings on this, I feel like this should be controllable as a user and not blockable by developers.
My single biggest pet pieve with my iPhone is when a developer (Google is a big offender) decides that instead of sticking with native design language they are just going to steamroll their own design language onto a device it wasn't meant for.
I feel like consistency goes a long way towards a better computing device.
Then you agree with this letter. It is calling put a specific issue and currently the only way to fix it would be to take away user theming by hard coding a stylesheet.
Since that removal of user choice is antithetical to these developers, they are looking for better solutions.
One solution is asking distributors to not apply themes to apps by default without doing QA on those apps.
The other solution is to provide apps a way to opt out of system default themes without those apps having to remove user choice by hard coding the stylesheet.
There is a third option and to me is likely the better option.
The themes are applied by default but there is somewhere to easily disable it on a a per app basis by the user and not by the app developer.
This makes it so some consistency is the default option but if something breaks then you can disable it. Maybe throw in some user education if you are really worried about this.
Edit: Also to be clear I don't really agree with the article. I understand some of the points it makes but considering downloading an app and it having a different UI is a frustration for me I would be very happy if on my iPhone I could somehow overwrite parts of that UI. (Ultimately right now I just uninstall it)
I think the UX of requiring users to opt out of untested and likely broken themes on a per app basis is bad.
I think an opt-in via prompt on first run (or whatever) is a better experience since it makes the distinction clear in case stuff breaks and provides an opportunity to warn users about potential breakage.
I'm on macOS but 99% of the time I feel the need to mess around with the appearance of a website or application or something it's because it is blindingly bright white instead of reading the room (or my dark mode setting, as it were).
The visual aspect of apps is a choice of the users, not of the developers. Please, let us users decide what colors, fonts and margins we see on our screens.
And to harp on this point- the destruction of the browser as an actual user-agent to style and present data is one of the biggest complaints about the maturation of the Internet.
Then you agree with these developers who think user choice is important and want to continue offering it to users with having distributors break their apps by automatically theming them.
> On a platform level, we believe GTK should stop forcing a single stylesheet on all apps by default. Instead of apps having to opt out of this by hardcoding a stylesheet, they should use the platform stylesheet unless they opt in to something else. We realize this is a complicated issue, but assuming every app works with every stylesheet is a bad default.
GTK2 has a large ecosystem of themes, and flexible (but slow) engines like pixbuf for those who don't want to write C. GTK3 broke that, but promised that its CSS-like styling would let a hundred flowers blossom as Web devs could contribute. Over a decade later and scouring OpenDesktop shows mostly just "flat design" and "flat design - dark mode".
I know that GTK vs Qt and Gnome vs KDE are holy wars, but GTK/Gnome seem to be squandering their position as the distro's default choice. Many standalone/third-party projects have jumped ship (e.g. PCManFM, LXDE, Audacious); I wonder if major distros will do the same (after all, Ubuntu wasn't afraid to push Unity).
PPPS: Does anyone know a (not yet broken) GTK3/4 theme which changes the scrollbars from their godawful default? I've been looking for years; I'd roll my own, but the lack of diversity across themes makes me worry it's too painful to bother.
(Written from Firefox (which uses GTK) on Phosh (a mobile-friendly Gnome compositor) on a Pinephone ;) )
C'mon. You are telling people that build and maintain core infrastructure used on millions of Linux installations all around the world that they are fundamentally misunderstanding Linux.
This is why I don't maintain free software, and God bless those who do.
If you look at the signees (especially the two or three that actually seem the most invested in this message, and responded to the discussion thread linked above), you will see that these are not the people building "core infrastructure" used by "millions". It's a random grab-bag of default Gnome applications, the kind most Linux users who are aware of alternatives immediately remove from distributions that ship it. "Random Gnome developers" as a group have been notorious for decades for not really gelling with the wider Linux ecosystem.
Looking at the project maintained by the front-runner of this movement, it has had 5 total reported issues in the last year, none of which are related to theming, so I'm not sure I understand what the big support struggle they're chafing at is either.
Do you actually disagree with any of the points I made? Or just the fact that I made those points to people who supposedly have positions of authority?
When did I get to be 'not a random person' around here? Heh, I know I have a high karma but my HN glory days are long behind me.
Anyway, since you asked:
> If you don't want people to theme your software (or rather, you don't want your software to be themed by distribution maintainers), why not write your own license forbidding just that? No one will want to touch it with a 10 foot pole, but hey, you won't have distribution maintainers theming your software.
This is just... Well let's just say it's you that doesn't understand free software. First off changing the license to deal with this is like solving a problem with your business by nuking your competitors from orbit. It's way way way too heavy-handed an approach.
Second, I dunno if you've ever actually worked in software before, but the people churning out the features, in this case the themes, more often than not don't really have a say in what they're building, even in the case of open source. Opening a public conversation like this is exactly how you solve this kind of problem. It's a democratic commons. Talk it out. There's no one person you can just email and say, hey, this is hurting us, knock it off.
You're basically just telling these people to shut up and take it. You don't care about their needs, or what they're going through every day. They make a website like this to stand up and be heard, and they hear your voice, hey, you over there, you're out of your lane, shut up and code.
It's... an immature response. The kind of immaturity that makes me believe that explaining why past the most basic observation would be an exercise in pissing upstream.
> They're like an arrogant chef who, after cooking your dinner, instructs the waiter to remove all the salt and pepper shakers from the table because they don't want you changing the flavor of their dish.
They are more like a chef who asks the waiters to not add salt or pepper to the dish before serving it to customers, because the customers will blame the chef then. If the customer adds a ton of salt, then it's clearly their fault and the chef says he is fine with that.
That will be an issue they will need to deal with because of the license they chose. They picked GPL (https://help.gnome.org/admin/gdm/stable/license.html.en) that means as long as the intermediary ships their changes too then all is good. They are basically asking to be the only fork of their code. I get it, they have spent tons of time getting it 'just right'. They may find that a hard sell to some integrators who make it a point to put their own spin on their distro. This is basically a 'do not fork our code' ask.
I get the idea. But the GPL allows for this? They would need a different license to get that? Pretty sure GPL is 'we may or may not give support if we feel like it' sort of license. The only real obligation is to provide the code including any changes you make.
This letter isn't a legal demand, this is a request to people who are interested in the health of the ecosystem and community.
The way similar sorts of issues are often enforced legally is by using trademarks so that if someone forks your project, they have to be clear that it is separate.
In this case, it isn't a fork and it's hard to see how those tools would apply but the underlying issue of user confusion and brand harm are still similar.
Oh I get that. But what many do not realize when they give the work away like in the GPL you also give away control. They have given away control but now are asking for it back. That is up to the distros if they want to do that. They are perfectly allowed to do so. But they are perfectly allowed to not do so. This is one of the 'downsides' to open source. People may use your source in a way you do not like. I have this same conversation every few years with people on the net. It is usually about the time they realize people are not giving stuff back up stream (their intent) but realty is GPL does not require that.
It basically is for a better term a fork. A small fork but a fork non the less. There are changes they are distributed downstream, but the rub is not back upstream. In this particular case people are going thru the trouble of making a theme pack that is kind of unfinished. But not finishing the work and not upstreaming it either for whatever reason. Hence the letter. But strongly worded letters do not always get things done. Maybe it will but I doubt it. The distros forked because the upstream was not doing what they needed. So the distro managers did it. But now they are asking 'just ignore that part of the GPL that says you can modify the code'. This is basically a missing feature of the upstream so downstream is adding it in.
I see both sides I really do. But if you give away code do not always expect it to be used in the way you expect.
You seem to have some fundamental misunderstandings about what is happening here.
> people are going thru the trouble of making a theme pack that is kind of unfinished. But not finishing the work and not upstreaming it either for whatever reason. Hence the letter.
No, this is not an "unfinished theme" for the specific app. This is a default theme that is being applied to every single app by the distribution.
> There are changes they are distributed downstream, but the rub is not back upstream
That is not the rub nor even tangentially related to the issue here. "Upstreaming" doesn't make any sense in this context.
> They have given away control but now are asking for it back.
> The distros forked...
Again, this has nothing to do with GPL other than as an analogy. This is not a fork, it is a user configuration feature. It is one that these developers could easily chose to disable by hardcoding styles (thus requiring anyone who wanted to customize the UI to fork and compile their own, which they would be able to do under GPL.)
However, the developers want to continue offering users this feature so are asking distributions to stop choosing a consistent look and feel across apps over the risk that their untested default theme break the underlying application without users being aware of why.
I personally don't understand how distributions would care so little about the negative impacts on users and developers. It seems perfectly plausible that distributions that care so much about a consistent appearance could QA the effects of their theme on core apps and then have a prompt on launch before applying their themes to apps which they have not QA'd.
You say you see both sides here, so perhaps you can explain why it makes sense for distributions to risk breaking apps with untested default themes without informing the user just to ensure that apps in the OS look similar.
> You seem to have some fundamental misunderstandings about what is happening here.
Upstream devs want to control what down stream devs are doing to their code/configs that are under the GPL and the downstream are doing a crummy job at it? What is to not understand? An open letter signed by a bunch of people saying 'dont do this to our code' sounds like they want some sort of control. They gave away that control.
> No, this is not an "unfinished theme" for the specific app. This is a default theme that is being applied to every single app by the distribution.
That sounds broken and unfished to me. I do not see it as anything but not finished. If 'bugged out' suits you better then just use that term. If the distro spent more time making it all look right that would be finished would it not? Distros do this allthetime to packages. I have dozens where I have to go unbork a broken package because of what the distro did or neglected to do.
>"Upstreaming" doesn't make any sense in this context.
Why not? They are making changes then shipping them but not contributing it back. It would make it easier on everyone else. But they want to keep their 'secret sauce' is my guess or lack the will to do the proper work to upstream it.
>You say you see both sides here, so perhaps you can explain why it makes sense for distributions to risk breaking apps with untested default themes without informing the user just to ensure that apps in the OS look similar.
They can totally do that. It is what most distros do to differentiate themselves from other distros. Some distros are bog standard no changes others have all sorts of tweaks to make their distro special. See something like an Arch vs RedHat. Arch is closer to 'no real changes other than recompiled for your machine and rolling release' whereas RedHat touches everything to make it special. This is usually considered a feature in the linux world.
That they are shipping broken themes is on the distro. As per the GPL again. The originators of the package are asking for a 'hey fix your junk'. That may or may not happen. The distro packages are under no obligation to fix it. They probably should but that does not mean they will. I have some distros I use where the packages are 3+ years out of date. Because no one maintains it.
You seem to be deliberately ignoring that GPL covers all of the files in the package. Including preconfigured items. That would include any preconfigured theming. The GPL does not really make that distinction. It is border line a 'you touched it last' style of working. It is one of the reasons people created CC licenses to make that distinction and what is the expectation.
I am not saying it is right or wrong. I am saying they are within their rights to do it. Why would they risk doing that? No idea. It is not something I would personally sign my name to. I would guess time, money, or lack of understand or a combination? Gnome would just be better off naming and shaming them and saying 'xyz distros are breaking our code be careful'.
That Gnome is saying 'please stop' is probably because they are getting all sorts of noise from broken distros. Put that at the top of your forum and say 'if you are coming from distro XYZ we may or may not look as they broke it here is a link to the distro forum'.
This letter isn't a demand, legal or otherwise. It's a collection of requests that along with arguments based on a shared interest in the health of the ecosystem.
You do realize that people do things or avoid doing things for reasons other than complying with the law right? This is one of those times.
The only place where GPL comes into it is that it makes sure that goodwill requests is such as this one are as far as it will go and distributions can't be legally forced to comply. That lack of legal force makes it more important to have a strong community to keep the ecosystem healthy.
So instead of ranting about "gah, they just don't understand GPL", it makes more sense to discuss the underlying problem, both on the technical side of how theming is implemented and on the cultural side of how default theming is explained and enabled.
The linked article has some more critical information. It sounds like GTK doesn't support themes (i.e. structured styling with mechanically enforced boundaries, guidelines, etc), and some people are using custom CSS overrides to emulate it. But this means literally anything could change, and app developers can't really defend about it, so apps break.
IMO I'd petition for GTK to support safe theming, and maybe build up what themes can do in a controlled manner over time, rather than just tell everyone to stop with the CSS. But maybe it's a foregone conclusion that GTK devs won't do this.
I'm sympathetic to users. I don't think devs have the right to force branding on users and there are good accessibility reasons to want themes, but its also reasonable for devs to want their software to not look like crap out of the box and there are carefully hand crafted UIs for specific uses that will never fit a theming standard.
GTK3 purposefully broke all that, in order to clean up the API, deprecate/replace various functionality, etc.. Fair enough, that's perfectly understandable; and necessary at some point.
> ... and some people are using custom CSS overrides to emulate it.
> tell everyone to stop with the CSS.
To mitigate the damage of losing all existing themes, the GTK3 developers switched to using CSS, so that:
- Theming would be much easier than for GTK2, reducing the effort to replace all those existing themes, and for making entirely new ones
- By replacing their old bespoke formats with CSS, hordes of Web devs would be able to join in with theming (this is also why the Gnome desktop embraced Javascript around the same time)
In other words, those "custom CSS overrides" are not only the officially sanctioned way to do theming; but the project implemented a major breaking-change in order to add CSS support, precisely for this reason!
This situation is entirely unlike, say, a Web site breaking due to someone's user-style.css. Web sites typically don't want anyone overriding their CSS, and they only use CSS at all because it's the only thing browsers provide. In contrast, GTK3 chose to implement CSS (previous versions worked fine without it), and they chose it so it could be overridden.
---
Unfortunately, this strategy did not work, at all. There was some initial effort at creating and porting themes; but each minor release of GTK3 broke them, requiring constant maintenance from their creators, until most just gave up. For example, see the GTK3/4 category on gnome-look.org ( https://www.gnome-look.org/browse?cat=135&ord=rating ) and notice:
- How many of the changelogs show breakages for every GTK update (usually the even-numbered ones like 3.16, 3.18, 3.20, etc. which are the stable releases)
- All of the comments (~one thread a year) reporting breakages, asking for updates for new GTK versions, linking to forks maintained by third-parties, reports that those forks aren't maintained anymore either, etc.
Over this time, Gnome's official position has changed to a combination of:
- We'll be adding better theme support soon, and it will be much better than before!
- The very idea of theming is an insult to our perfect decisions and aesthetics
NOTE: Gnome/GTK developers have pissed off so many people with their 2->3 transition that Gnome 2 got forked into the Mate desktop; the Cinnamon desktop forked Gnome 3 in order to clone Gnome 2; and many projects have been abandoning GTK in favour of alternatives like Qt, e.g. Audacious did so recently.
I use Linux because I like tweaking my system and that includes theming. I agree that people shouldn't report bugs if their custom theme makes an app goofy or broken but to suggest that people and distros should not use custom themes is ridiculous
Imo you and the author of the article seem to agree
You're not recommending blanket tweaks for all users and are savvy enough to remove the theme (or fix it) if it's breaking an app you want to use before reporting issues
My impression of the article is a request against generic re theming.
I suspect there's a better path forwards though. Eg distros could make their themes more modular (relocation of UI elements, changing colors, changing icons - maybe this already happens!) and then make it easy to toggle these when opening a new app (just like the OS gives you a minute to decide if your monitor display settings tweaks broke something for you)
As a user, I'd appreciate it if these developers did disable theming in their apps - at least as a config switch.
If an app hasn't been properly tested with numerous themes the chances are that it'll break. The default Pop OS dark theme messes up several apps and it's a pain to poke around and fix them by editing obscure files. If it doesn't support theming I'd rather it look out of place than be partially illegible.
Also, sometimes even if I like things dark in general there's some software which just feels wrong if it's not light - like a word processor. The white background is representing paper, I don't want that to be inverted - and I don't want the toolbars etc to go dark either, because the contrast against the white page becomes unpleasant.
A lot of folks seem pissed off by this, but it cannot be denied it adds a lot of headaches for developers. Specifically really demoralizing to UI/UX devs who try and bring their skills to the open source world (either they are designing UI that is getting overhauled by themes, or they're designing themes that are getting shunned in missives like this).
But all of this feels like an expectation of folks who want the free software ecosystem to more closely resemble how their disciplines function in the hierarchical divisions of responsibility and control in the private corporate world.
The first screenshot (CSS Theming) shows an app that doesn't use standard background color (?offwhite?), but uses standard font color. Normally this works, as standard font color is something dark (?black?).
And the problem becomes when user opens the app in dark mode, the background color stays non standard (?offwhite?), but the font color stays standard, which in dark mode makes fonts bright (?white?).
The question is:
If developer is ignoring theming, why don't they hard code both background and foreground colors?
There is one solution : stop using off theme coloring
This is squarely for developer to fix.
But since they want Gnome/GTK to fix this, here are potential options:
- Gnome / GTK should implement that if someone wants to use non standard, off theme colors, then developer has to always define foreground and background color. --- not sure how feasible it this with nested frames
- Gnome / GTK should disable allowing changing colors to specific values, and only allow changing by rotating Hue (aka 5% rotation of Hue 'clockwise') and by changing saturating (aka 5% more grayscale) and by changing brightness/contrast in relation to paired color (aka: background 5% closer shade to font)
- Gnome / GTK should define more color pairs , kind of like bootstrap has primary/secondary/success/danger/warning/info/light/dark coloring for all components in a single theme
Moved from iOS to Android recently and the first thing I did was install a new FOSS launcher and Articons. The Settings menu and sharesheet still show the original app icons. App theming choices are much more limited, just hope they respect your system theme and font scaling, which the latter definitely can break layouts rendering some apps unusable.
I don't really have a point with all of this; I just think there's a middleground that can be met to let users modify whatever they'd like, and straying from the Happy Path that devs test for could show a warning or a way to let them choose to revert certain system defaults for your app.
On the one hand, ui consistency is a thing, and everyone making up their own paradigm is not great. (And the linux desktop is already highly inconsistent as is).
But I think we passed that station a long time ago.
On the third hand, if you do have themability, it ought to not break apps that are thus themable. I'm not sure if that's an app problem or a gnome problem or a both problem here.
In the main "please don't theme our app" might be the wrong approach though. It somehow seems to go against the spirit of open-sourceness. Not saying the issue is with the upstream dev per-se, but something is definitely going wrong here.
The soap refill bottle that I use has "Please, don't dilute it with water" written on its side. No explanation, no warning, just this. With the equivalent of "please" in my language.
I always got super fascinated by this, they ask me such a random thing, that shouldn't really affect them (okay, I buy less soap if I dilute it with water), but makes my life worse.
I have a similar feeling with this article. You want me to use the original icons. Okay, noted. When I decide if I want to replace the icons, I will probably consider the wish of the creators too. With a weight approximately 0%.
Fwiw, I think the exhortation not to dilute the soap with water is equivalent to saying "our guarantees disappear when you add uncontrolled substances into this bottle"
Essentially: the warranty is void. Tap water can contain bacteria that a soap manufacturer can't possibly account for [1]
This actually makes a perfect analogy for the original post - even though there was no guarantee or warranty (it's free software) when you theme your computer, it makes dealing with bug reports difficult. It makes screenshots misleading.
If you want to theme your computer, they actually specifically say that's fine, but I imagine they would appreciate 1) noting what theme you use on screenshots (much like noting the prompt that generated an image) or removing the theme when taking screenshots and 2) try debugging and reproducing issues with the theme turned off.
If you're developing software and >50% of the bug reports you field are because people are doing something unsupported that is frustrating
I think that goes against the philosophy of free software, also, as long as there’s no standardized way of making these icons, I absolutely support theme-ing them so at least I have a consistent look when I open my apps drawer, to be honest, a lot of free software developers are great programmers but they are horrible when it comes to visual design, UI or even icons.
Almost every Windows app discards the default theme in favour of some idiosyncratic mess. It sucks.
If a distro's default theme breaks an app then it's something the distro and app will have to work together and fix. But throwing system themes out in favour of app specific themes like the article is arguing for sounds absolutely awful.
Request to GNOME app developers. Don't move the most common buttons to the Header Bar while also not getting rid of the toolbar. This makes my most common actions further away from where my mouse is most likely to be.
If I encounter a bug, I'm not going to force the developer to deal with my themes. If I'm filing an issue, one of the first things I do is a fresh install to consistently reproduce it, which means no themes.
Agree. I think it hurts the brand of the apps when they're themed, in that I load it and it looks jumbled and broken and I instantly think oh they dont care how this looks
interestingly, of the applications whose authors have signed, i only ever tried geary some time ago and concluded it was way too feature-poor and inconvenient in terms of the user interface to serve as a mail client.
never had an incentive to install any of the others.
(i have been using linux full time, both personally and professionally, for the last two decades).
Gnome is not an OS or a "platform", it is free (as in freedom!) software to be used and tied together however the users, distro authors, ansd whoever else feels like.
Writing and publishing open source software then trying to guilt trip people into interacting with it at arms length and subject to condiions like closed source, proprietary software is nuts.
I honestly couldn't care less if all these people quit writing software tomorrow, if the alternative is this nonsense.