Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please don’t theme our apps

stopthemingmy.app

Post reply on HN
Print view View original

181–190 of 206 posts

Re: Please don’t theme our apps

#181

Post by Legogris »

rhinoceraptor wrote: post #180
Legogris wrote: post #36

I couldn't disagree more. If the user wants the intended experience, they will not apply a different theme for your app. The whole reason a user has applied a different theme on your app is because they disagree with your choices and that's totally fine. What's next, asking Mozilla to take down user style sheets and extensions that restyle web apps? This article is antithetical to the whole cultural foundation that G…

They're specifically talking to distros in the letter, not end users. If you want to install your own custom theme, fine. But if you're a distro shipping a custom theme, when it breaks a 3rd party app, the app gets the blame, not the distro.

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

This is what I take issue with as a user. A major reason why I prefer GTK is exactly because I can get a homogenous look without having to tweak every single app individually. There are definitely issues with the way this is handled (and I'm TBH still confused about squaring Qt and GTK styles), but let's not throw out the baby with the bathwater.

Re: Please don’t theme our apps

#182

Post by TeMPOraL »

sjwright wrote: post #151
TeMPOraL wrote: post #127

Earlier quoted context omitted.

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.

Nobody is saying that you must not apply your favourite theme to whatever apps you like on your own computer. Not me, not the linked article. If themes are so important to you, pick your app based on that criteria. If you think an app is garbage because it doesn’t theme well, fork it and write a better version yourself.

The main point of confusion in this whole thread is whether or not the article states you shouldn't apply themes on your own computer. To some, myself included, it kind of does. Linux distributions are not individual operating systems - they're essentially skins on top of Linux kernel, created bottom-up to offer opinionated choices to users. Picking a distribution is like modifying software on one's own computer, except without duplicating the same work other people would do. In this sense, the article does ask users to not customize software on their own machines.

Re: Please don’t theme our apps

#183

Post by [deleted] »

Legogris wrote: post #181
rhinoceraptor wrote: post #180

Earlier quoted context omitted.

They're specifically talking to distros in the letter, not end users. If you want to install your own custom theme, fine. But if you're a distro shipping a custom theme, when it breaks a 3rd party app, the app gets the blame, not the distro.

> 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. This is what I take issue with as a user. A major reason why I prefer GTK is exactly because I can get a homogenous look without having to tweak every single app individu…

[deleted]

Re: Please don’t theme our apps

#184

Post by derefr »

Arctaire wrote: post #3

I feel like an "open letter" is a pretty odd way to ask something of the maintainers of distributions that do not install GNOME with its stock Adwaita theme. Indeed, despite being created some two weeks ago, the (small) notice at the top that this particular open letter is aimed only at distribution maintainers was only added yesterday[1]. How many do so, anyway? I know Ubuntu has the Yaru[2] theme by default. I'll a…

> I'll add that I personally find the stock Adwaita theme to be total garbage.

I mean, it doesn't really matter if it's garbage or not; it matters that it's what GNOME app developers are testing their UX against, so if you create a theme that changes the metrics drastically from the ones in Adwaita, your theme is going to break those apps.

You can probably get away with tweaks on color, squashing some elements narrower, whatever, but that's not what the post is really talking about. Things that could be called "variations on Adwaita", or "Adwaita if it had a fancy control panel with metrics sliders and color pickers", aren't gonna break anyone's apps.

They're talking about themes that e.g. change fonts on control labels to ones that don't have the same em-widths or x-heights for some characters, and so things stop lining up flush; or which replacing the icons with an icon set that isn't just "the same icon designs but now in monochrome/superflat/etc." but now has new designs, different to the same degree that the iOS vs. Android emoji themes are different, such that your gun becomes a water gun (or your homedir becomes a hand throwing devil-horns.)

Re: Please don’t theme our apps

#185

Post by derefr »

gmueckl wrote: post #32

Color themes seem like a brilliant idea until hit the point where your custom control needs this one extra distinct highlight or background color to convey state. Then you're out of luck. You only have bad options left: opt out of system theming and enforce your own or hardcode a color (or put it into the settings dialog) and accept that it breaks with any non-default theme out there because no user will take time to…

There's nothing stopping a graphics toolkit from following the lead of Bootstrap and having N different "semantic tints" with names like "primary", "danger", "done", "busy", "paused", etc.; where the theme designer then gets to define, for their theme, what color "primary" or "danger" will be—but ensures that that color coherently means only that semantic idea throughout the theme. (So if they create a theme where "danger" is blue, then the window close caption-button should have a blue background, the delete-permanently icon should have blue as its primary, etc.)

Re: Please don’t theme our apps

#186

Post by gmueckl »

yellowapple wrote: post #178
adamzochowski wrote: post #171

Earlier quoted context omitted.

As an application developer I want for my users a consistent experience, irrelevant of OS or distribution. I understand that. But, as a user I want for my experience consistent on my os, irrelevant of that different apps are written by different people on different setups. I want consistent icons, I want menus that follow same convention, I want to change text colours and sizes. The biggest issue is that developers d…

I have a strong feeling that if custom themes are breaking apps, then those apps are almost certainly in violation of one or more of tables 2-4, 2-5, or 2-6.

Maybe, maybe not. Some apps have no obligation to meet these checklists because they are for tasks that can only be performed by people with no significant visual impairment. I am not claiming that this a common case. But how would e.g. someone with poor eyesight use gimp successfully? Dumb line of business apps that have a simple UI made mostly out of standard widgets have fewer excuses.

Re: Please don’t theme our apps

#187

Post by gmueckl »

anoncake wrote: post #149
gmueckl wrote: post #139

Earlier quoted context omitted.

That is not enough. What if I need three clearly distinguishable background colors to convey different states for list entries?

Then you should fix your app so it can be used by color-blind users. Aside from that, you should use distinguishable background colors A, B and C specified by the system color theme. It's more likely that its designer has considered accessibility issues than that every single app developer has.

Have you looked at the set of colors that is actually defined by a theme? That is my point: I would use these colors gladly if they were there. They aren't.

Re: Please don’t theme our apps

#188

Post by gmueckl »

derefr wrote: post #185
gmueckl wrote: post #32

Color themes seem like a brilliant idea until hit the point where your custom control needs this one extra distinct highlight or background color to convey state. Then you're out of luck. You only have bad options left: opt out of system theming and enforce your own or hardcode a color (or put it into the settings dialog) and accept that it breaks with any non-default theme out there because no user will take time to…

There's nothing stopping a graphics toolkit from following the lead of Bootstrap and having N different "semantic tints" with names like "primary", "danger", "done", "busy", "paused", etc.; where the theme designer then gets to define, for their theme, what color "primary" or "danger" will be—but ensures that that color coherently means only that semantic idea throughout the theme. (So if they create a theme where "d…

That may be the right approach. But desktop toolkits don't do this.

Re: Please don’t theme our apps

#189

Post by gmueckl »

adamzochowski wrote: post #171
gmueckl wrote: post #142

Earlier quoted context omitted.

Number two is the enforced theme I was tslking about. Offset colors can be problematic for a number of reasons. The main one is that you don't know if the color that is generated that way has the right amount of contrast to each of the other colors it appears with and that the end result is something that is visually pleasing.

As an application developer I want for my users a consistent experience, irrelevant of OS or distribution. I understand that. But, as a user I want for my experience consistent on my os, irrelevant of that different apps are written by different people on different setups. I want consistent icons, I want menus that follow same convention, I want to change text colours and sizes. The biggest issue is that developers d…

The way I see it, there are two options here: either require themes to specify colors for many more semantic use cases or give up on themes.

Icon consistency is also just not possible. Any halfway decent application with a properly designed UI will have a set of prominently displayed custon icons for the main commands that make the software what it is. There is no way that these icons can be consistent with whatever random theme you chose to use today.

Post reply on HN