Please don’t theme our apps | Hacker News Reader

Please don’t theme our apps

stopthemingmy.app

43 pointsfsflover87 comments

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.

Clarification here: they are asking you to not, and warning that you're getting into "unsupported territory".

Unless both parties signed a contract, there is no "supported territory".

The GPL clearly states that there needs not even be a particular purpose.

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.

Fair.

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"

    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.

A lack a warranty is very different from a lack of QA and documentation.

Yes, but asking you to not submit issues about your one-off theme working with an app seems reasonable.

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.

[1] https://regolith-linux.org/

> 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.

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.

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.

[1] https://regolith-linux.org/

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.

> 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.

> 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.

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!)

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.

> 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.

[0] https://www.gnu.org/philosophy/philosophy.html

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.

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.

> 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.

Make sure your app has a good native dark mode and I won't theme anything.

Yes, exactly this.

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).

A black theme. Black. Not dark gray, not slightly teal, black. Flat, everything, solid black but interactive elements and text.

I used an app on my phone recently that had an AMOLED option, clearly labelled AMOLED, that was gray. These people are crazy.

I'd rather say: "Please don't theme your apps" !

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.

> Though we could disable theming directly in our apps, we do not want to resort to this.

Lol, I look forward to the followup sites:

  StopPatchingThemeSupportBackIntoMy.App
  StopDistributingYourOwnBuildsOfMy.App
  StopUsingTheMorePopularForkOfMy.App

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).

PS: OK, I admit Vertex is quite nice; but GTK seems to keep breaking themes with each point-release https://www.gnome-look.org/p/1013757

PPS: Are we really calling things "apps" now?

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 ;) )

Issue I opened explaining why this doesn't make any sense (2020): https://github.com/do-not-theme/do-not-theme.github.io/issue...

The responses from GNOME members were quite enlightening. Really shows the level of respect they have for anyone besides the in club.

> 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.

[1] https://github.com/do-not-theme/do-not-theme.github.io/issue...

And just before that

> Just because something is technically possible and not illegal doesn't mean it's not a dick move

[1] https://github.com/do-not-theme/do-not-theme.github.io/issue...

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.

Sounds reasonable to me.

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.

> It's a random grab-bag of default Gnome applications,

Default applications! On one of the two major desktop frameworks in Linux!

Oh I'm sure what you're working on is so much more important.

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?

Yes, I do. But it's clear the words would be wasted when the perspectives are that far apart.

Then why did you reply? I didn't ask you.

Everybody has a voice here, buddy. I'm exercising mine. You don't get to pick and choose who gets a say.

I'll be honest I misread your username before; I thought you were a random person responding to my question. That's why I responded like that.

Still seems weird to not share your opinion...

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.

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.

> It sounds like GTK doesn't support themes

> I'd petition for GTK to support safe theming, and maybe build up what themes can do in a controlled manner over time

GTK already supported themes! In particular, GTK2 has loads of themes (e.g. see the GTK2 category on gnome-look.org https://www.gnome-look.org/browse?cat=136&ord=rating ). Not only did artists create a wide variety of themes, programmers also wrote many "theme engines" to extend the theming capabilities of GTK2, e.g. see all of the "gtk2-engines-foo" packages in Debian: https://packages.debian.org/search?lang=en&searchon=names&ke...

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.

Also, compare the Debian link above to this search for GTK3, which only shows one transitional package and one from their "oldoldstable" release: https://packages.debian.org/search?suite=default&section=all...

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.

Previous discussions...

- 2023-09-26 (1 comment): https://news.ycombinator.com/item?id=37655658

- 2021-09-03 (80 comments): https://news.ycombinator.com/item?id=28400337

- 2021-05-15 (4 comments): https://news.ycombinator.com/item?id=27167115

- 2019-05-25 (194 comments): https://news.ycombinator.com/item?id=20008396

- 2019-05-24 (1 comment): https://news.ycombinator.com/item?id=20000358

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.

I don't understand the issue?

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.

I'm a bit torn on this one.

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

[1] https://www.washingtonpost.com/lifestyle/wellness/why-you-do...

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.

I don't quite understand to whom exactly is this addressed? Distro creators/maintainers, ok it makes sense. But end users?

Distro creators and maintainers yes. End users when reporting bugs.

If you don't realize your distro is theming that's also something you should know.

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.

Amazing how much good prefixing the title with "Distro maintainers:" would've done.

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.

This is exactly the type of confusion at issue here.

A "fresh install" doesn't necessarily remove default themes applied by the distribution.

Ahhh, that's a good point. I guess I'm used to theming applications individually.

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).

Funny how this only seems to be an issue with GTK apps, and not with QT.

"App Icons are the identity of an app. Changing an app’s icon denies the developer the possibility to control their brand."

Oh shut up Gnome, this is why nobody likes you.

Lol fuck you if it's on my computer it's my app.

don't care. theming anyway.

Reply on news.ycombinator.com