Live data from Hacker News

Please don’t theme our apps

stopthemingmy.app

121–130 of 206 posts

Re: Please don’t theme our apps

#121
post #2

> GTK Stylesheets can make applications look broken, and even unusable. Bugs are bad, yes. > Icon Themes can change icon metaphors, leading to interfaces with icons that don’t express what the developer intended. That is not a problem if you use icons for the purpose they are intended for. > Changing an app’s icon denies the developer the possibility to control their brand. Good. My computer is not your billboard. Co…

>Good. My computer is not your billboard. Consistency is more important than your "brand".

completely agree with this point.

Re: Please don’t theme our apps

#123
post #9

Icon themes - should be more standardized, that's true. GTK stylesheets - mostly a problem of different GTK versions they're made for, because GTK versioning is a mess. App Icons - so what? I think most people like consistency - look at Windows 10 and its ~4years of development, it's still a mess and if I had an option I'd switch right away All in all I think the choice should be left on the user after distro install…

> Icon themes - should be more standardized, that's true. Why? There is already a standard. It does not specify what icons look like, but what they mean. Replacing an icon with another that has the same meaning is not a problem. Of course, if you, say, abuse the "system-search" icon to show a looking glass, this will not work with a theme using a different metaphor. The icon theme displayed in the open letter is just…

Meaning isn't binary and "system-search" could mean many different subtly different things depending on the application and the context. Often the choice of icon requires context that factors in the specific iconography.

For example, what happens when there's system searching element that needs to be in visual proximity to a magnification, zooming or loupe-inspection element? It's impossible to know if an icon theme is going to maintain consistency and/or disambiguity with the default theme.

Re: Please don’t theme our apps

#125

This is more of an indictment of the way GTK3+ handles theming (or lack of it). GNOME/GTK devs, as usual, got confused and implemented something no one wants. Either you provide a proper and defined way to theme like KDE does or take the windows/mac route and tell developers to recreate any custom themed control from scratch. Instead, they go around saying that there is only one GTK theme and then leave a convenient…

> This is more of an indictment of the way GTK3+ handles theming (or lack of it).

How do you think GTK+3 handles theming (or lacks handling for it)? It sounds like you're confusing GTK+3 theming for GTK+2 theming (which was based on "engines", which were quite a mess). Now it's very "proper and defined", it's accomplished with a strict subset of CSS which has fairly consistent behaviour.

I personally don't see the point in elaborate theming systems (I'd prefer to just have control over the colours, and maybe one or two of the spacing variables), and it is obvious that they cost a lot of cycles at run time....

but GTK+3's theming system is not braindead, it's just ambitious.

Re: Please don’t theme our apps

#126

This is more of an indictment of the way GTK3+ handles theming (or lack of it). GNOME/GTK devs, as usual, got confused and implemented something no one wants. Either you provide a proper and defined way to theme like KDE does or take the windows/mac route and tell developers to recreate any custom themed control from scratch. Instead, they go around saying that there is only one GTK theme and then leave a convenient…

It is indeed easy to read this and conclude gtk3 has lost its way. eg. I remember in gtk1.2 days, there were a crapton of themes and they did radical things, and that was kind of the point.

Re: Please don’t theme our apps

#127
post #37

Earlier quoted context omitted.

It is not a reasonable request, though. End users want the ability to theme their system, and you cannot expect each end user to make their own themes. People rely on distributions for this to happen. I understand that the devs do not want to be responsible for bugs stemming from broken themes, but this is the wrong solution. Ultimately the solution is a better theme API, not this which would essentially stop custom…

It doesn't matter if the end users want the ability to theme their system—if the software they run is not designed to be themed, then it's not designed to be themed.

It doesn't matter if the software is designed to be themed. If I want it to be themed, I'll theme it anyway, and if I can't, it means the software and the platform it's running on is garbage, and I'll go find a different one.

Re: Please don’t theme our apps

#129
post #37

Earlier quoted context omitted.

I don’t take issue with people expressing opinions, or even pointing out that theming is a platform feature. But I do take issue with attacking developers who write applications for free, and contribute to the Linux ecosystem, for making a reasonable request to platform developers.

It is not a reasonable request, though. End users want the ability to theme their system, and you cannot expect each end user to make their own themes. People rely on distributions for this to happen. I understand that the devs do not want to be responsible for bugs stemming from broken themes, but this is the wrong solution. Ultimately the solution is a better theme API, not this which would essentially stop custom…

Theme API could be an improvement, but it isn't a perfect solution either - because the same complaints with the same arguments show up in relation to distros patching application code. It's a general problem of who changes the software. Some FLOSS developers seem to desire to have "producer/consumer" relationship with users of their software, seemingly forgetting that the entire point of FLOSS is to make this relationship model impossible to enforce.

I don't see a good technical solution here, but I see two social ones: a) developers of FLOSS must understand they're writing software that can and will be modified and re-released by others, sometimes individuals and sometimes organized groups (like people making Linux distributions); and b) users need to understand that if they have a problem with their software, they should reach out to people from whom they got that software for support. If you got a program from developer's home page, you should contact them directly. If you got it from your distro, then distro maintainers should be your first line of support.

(Also c), some users won't understand b), and forwarding support requests to appropriate people is just part of publishing FLOSS.)

Re: Please don’t theme our apps

#130
I honestly think we just need to have light and dark modes built in. If you want to modify the dark theme a bit, go ahead, but since the original dev knew the background should be dark and the foreground light, it should be OK. The problem is when people implicitly assume a light theme, but then use a dark one. If we could "tag" a theme as light or dark, a lot of this problem would go away.
Post reply on HN