
Please don’t theme our apps - forlorn
https://stopthemingmy.app/
======
random45345
The whole letter sounds weird when talking about free software. Software
freedom main benefit is that the user can change the software. Theming it is
probably the most accessible form of modification and should be celebrated.
Asking not to theme is contrary to the free software ethos itself.

The situation is even more tricky as what is being modified is not even the
software itself but the system dependencies. Essentially the developers in
this letter say: do not run our software on an environment that is not the one
we support (in practice fedora or a close clone of it) and if you create a
distro make sure its a clone of what we support.

I understand the fact that developers do not want to support bugs due to user
modifications and strange environments. Free software doesn't imply free
support so they can put any restriction on what they want to do. The letter
however would have been much less weird if it said "we cannot ensure quality
of software X except on our build running on a supported environment, if you
run the software elsewhere or with changes (and theming is a change) please
don't call it X to avoid confusion and remember you are on your own".

What Firefox did I think its a smart solution to this problem. " We offer
Firefox on platform x,y,z. If you build it on something else, call it
something else, if you run it on another platform remember you're on your
own".

~~~
turbinerneiter
This isn't about the user theming. It's about distros theming.

There currently is a growing conflict between upstream developers and
distributions, because some of their interactions and dependencies bare badly
managed.

For example, upstream maintainers see an influx of bug reports and angry users
due to bugs, where the distributions are at fault. Sources for this can be
changes to the code that the distributions make for various reasons like
backwards compatibility, themes that break user interfaces or simply outdated
packages or missing backports.

The GNOME upstream maintainers all are having their ass hanging out on a
public gitlab repo, while some of the distributors, who break stuff, are very
hard to find, with sometimes ancient bugtrackers.

I trust that the community will find a way to update their relationships and
solve these issues, but it starts with seeing what's going wrong and where we
have bad incentive structures.

~~~
random45345
I guess a radical solution would be to require (through trademark law) to
force distros to brand the apps differently (name and icon) so that bug
reports end up where they belong.

~~~
anoncake
Debian used to have to do this with Firefox and Thunderbird.

~~~
sangnoir
Firefox was branded "IceWeasel" on Debian - an unsubtle dig at Mozilla, which
I found hilarious (and a little juvenile). I'm glad they resolved the issue.

------
quantummkv
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 backdoor open for hacks with a nudge and a wink. Either open the
front door and roll out a carpet or close all the doors and windows.

~~~
microcolonel
> _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.

~~~
quantummkv
Um no, because gtk/gnome devs have explicitly stated that Adwaita is the one
true gtk theme. The name "Adwaita" reflects it. In GTK3+, the concept of
themes does not exist. This is why you need 3rd party tools to change them.
This is why 3rd party themes break stuff that this article complains about.

------
Arctaire
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 add that I personally find the stock Adwaita theme to be total garbage.
I've been using the Vimix dark themes[3] for as long as I can remember because
they don't make the title bar of windows 30 storeys tall and they don't use
beige.

1\. [https://github.com/do-not-theme/do-not-
theme.github.io/commi...](https://github.com/do-not-theme/do-not-
theme.github.io/commit/72fb77415c5f5dfe8fdee3a183cedf2024d1b21e)

2\. [https://github.com/ubuntu/yaru](https://github.com/ubuntu/yaru)

3\. [https://github.com/vinceliuice/vimix-gtk-
themes](https://github.com/vinceliuice/vimix-gtk-themes)

~~~
TeMPOraL
You don't write an open letter when you want to ask someone something; you
write one when you want to force them to do things your way by creating a
public shitstorm.

------
Legogris
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 GNOME
builds on, without which there would probably not be an open source desktop
ecosystem to build apps for.

I strongly urge the authors to take in the arguments of the top comments and
reevaluate their positions.

And you know what? The more you enable and facilitate customization, the
better and richer will the options provided by the community be. I can see how
the argument makes sense for _particular distributions_ like Elementary OS and
maybe Linux Mint that are aiming at a unified experience for novice users. I
really hope other distro maintainers don't pay attention.

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

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

------
lousken
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,
use default gnome look by default and have an option to switch to another with
a warning. I agree that devs shouldn't have to deal with someones custom
stylesheet issues.

~~~
anoncake
> 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 garbage. Using it as an an
example is like saying distributions should not change the default font
because they might choose Wingdings.

~~~
JasonFruit
> The icon theme displayed in the open letter is just garbage.

A _lot_ of icon themes are pure garbage, or at least incomplete. I don't think
the example chosen here is any worse than what I've seen on my own system.
Honestly, _most_ icon themes are a failure; visual metaphors are just plain
hard, and there's no substitute for literacy.

~~~
anoncake
True. But what about the icon themes major distributions pick?

~~~
JasonFruit
That's fair; the major distributions usually choose better themes. There are
also minor distributions, however…

~~~
anoncake
Minor distributions have a minor impact. And the few people who use them
presumably do so because they like the weird choices the distributions make.

------
coleifer
The gnome/gtk team introduces breaking changes to the styles and themes _all
the time_. I think this is misplaced outrage.

One of the things I like most about gtk apps is the ability to theme them to
achieve a uniform look across all my apps. I would rather use a slightly less
functional gtk app than a qt/kde thing for this reason.

Users who care enough to mess with themes by necessity accept that sometimes
things may need some tweaking. Most popular themes are on gh and have
responsive maintainers who are invested in their themes looking good/uniform.
The burden should be placed on the theme maintainers and the users who choose
to use non-default configuration, rather than disabling themes on an ad-hoc
basis.

------
Pxtl
I could see a very similar article written for "please stop letting users
resize the window" or "please stop letting users change font size"

~~~
quotemstr
Yeah. This has a whiff of that "let me disable the back button!" whining from
1990s webdevs.

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

~~~
spronkey
I think you're onto something, but I don't think it's as simple as just having
a "light theme" and a "dark theme".

I think that if we're going to have toolkits that support custom, nested
widgets, those widgets need to be designed to support the _context_ they are
in. There will _always_ arise situations where normally-light widgets need to
appear on a dark background, or vice versa. The nested path bar example is
exactly this - it's a widget that supports a single context (light
background), but is having two contexts forced on it by leaky style cascades
(light text, but also light background).

How about we bake the concept of "light" and "dark" into the widgets
themselves and take advantage of the cascading nature to switch the theme of a
widget depending on the context it is in.

Realistically though, GNOME 3 was rather short-sighted when it came to themes.
Windows 95 showed us the way 24 years ago: you can change the colours of
anything you want. You can tweak the size of most things. You can change the
fonts. You can change the icons. Simple API that gets applied on top of an
existing theme. Expand this for 2019 with dark and light variants for each
theme, and I bet we'd satisfy almost all users.

------
jrockway
Don't release your software under a free software license if you don't want
redistributors to randomly add bugs. Just go work for Apple, or something.

------
NyashMyash
Bullshit. I need dark theme and I don't care about "brands" nor "identity".
Stop burning my eyes please.

~~~
anoncake
I think a dark theme is the one thing Gnome supports aside from the default.

------
core1024
I agree that changing default icons is sometimes confusing. The user have hard
times finding an app. Especially apps like Geany, Firefox and VLC get so weird
icons in some themes that you can't visually confirm that this is the correct
app.

I also agree that if you make an app screenshot/tutorial it is better to use
the default theme unless you are targeting users for specific distro.

However I see some flaws in Adwaita (the default GTK theme) and a lot other
themes regarding the titlebars:

1\. They are too tall for no obvious reason.

2\. the most irritating thing is that it is very hard to tell the active
window. I mean it is a bit lighter but that's all.

------
eximius
Okay, this is maybe more reasonable than I expected. I believe distros
shipping non-default stylesheets are the target here? They seem to explicitly
acknowledge users can do whatever they want.

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

Which is a sentiment I can get behind. Telling distributors that they need to
make it clear the styling might break things is not wholly unreasonable.

------
gmueckl
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 look at the settings and fiddle with
the colors. Either way, any usability benefit from good default themes (e.g.
high contrast themes) is pretty much gone.

~~~
adamzochowski
There are two solutions to this:

1) use offset colours, like specifying to move 10% in Hue off the theme
colour.

2) specify all foreground + background colours and admit that this is special
and won't conform to any user or distro theming

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

~~~
adamzochowski
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 don't want to follow gnome checklist.
Instead of that, they hardcode colours and behaviour. They go heavy into 'it
works for me'. And then have audacity to complain that world doesn't bend to
their will.

Here is a gnome checklist. I wish the open letter stated how their application
follows the checklist and was broken by a distribution so that the checklist
now includes fails.

[https://developer.gnome.org/accessibility-devel-
guide/stable...](https://developer.gnome.org/accessibility-devel-
guide/stable/gad-checklist.html.en)

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

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

~~~
spronkey
As strange as it may seem, blind people can be quite good at resizing images.

------
jchw
It’s weird how theming seems to have never been an issue for decades on KDE
and KDE apps. It’s almost as though it’s a technology issue.

------
nycticorax
I have a lot of sympathy for the signers of this letter. As Havoc Pennington
(team lead of the GNOME 2 project) liked to point out, every option you
provide to users has a cost to the developers in terms of testing and
maintenance. Maybe a better way for the letter signers to communicate their
position would be to simply say "We don't support nonstandard GNOME themes".
Certainly, they're within their rights to say this, and you're within your
rights to not use their apps if you don't like it.

Another thing Havoc Pennington liked to talk about in developing GNOME 2 was
'crack'. These were things in GNOME 1 that were bad for the community, but
that a lot of users were addicted to. Like, for instance, an overabundance of
user settings.

By all accounts, it's hard to write a GUI app for the Linux desktop, in part
because of the huge variety of distros and desktops, and apparently even
themes within a single desktop. And as a user, my biggest complaint about
desktop Linux is the relative paucity of high-quality applications. (Yes, I
know there are many high-quality desktop Linux applications. But there aren't
as many as on Windows or MacOS.) I can't help but wonder if most of the
community wouldn't be better off if a single distro, hopefully with a single
desktop and a single theme, decisively 'won' and claimed a dominant usage
share of the Linux desktop. Then third-party developers would be incentivized
to just develop for that distro, which might make the lives of both users and
developers better in the long run.

And of course, since it's open source, if 'the one true distro' went off the
rails eventually, someone else could fork it and become the new 'one true
distro', with relatively little danger of vendor lock-in.

~~~
nycticorax
This blog post provides rebuttals to some of the points made in this comment
thread:

[https://blogs.gnome.org/tbernard/2018/10/15/restyling-
apps-a...](https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-at-
scale/)

That blog post was linked to from here:

[https://github.com/do-not-theme/do-not-
theme.github.io/issue...](https://github.com/do-not-theme/do-not-
theme.github.io/issues/7)

------
Avamander
Yikes.

I'll stop themeing apps and their icons once I don't see a single piece of
software that has an UI and an icon look like as it were made in the 90s, also
implement dark theme. Providing a more consistent UI for new users on a distro
is also better idea than leaving it up for the developers.

The GNOME back button being wrongly themed is solved by switching GNOME to
dark mode (`gnome-tweak-tool`) and a dark theme. The engine isn't the best but
devs don't make it easy either.

------
code_duck
It reminds me of how Reddit allows subs to put in their own stylesheets. Each
sub can change the look, placement, and existence of just about every UI
element. It makes for the most inconsistent interface I've ever seen for a
website.

~~~
Zak
The redisign used for new.reddit.com doesn't give moderators as much control,
much to the displeasure of many of us who have been on the platform for a long
time.

Although I dislike it when people significantly change UI controls.

~~~
yellowapple
I can't think of any CSS styles that are actually outright _bad_ , though,
unless it's intentional (like with /r/crappydesign or /r/ooer).

~~~
code_duck
Just the inconsistency makes it very unusable.

~~~
spronkey
I respectfully disagree for the large part. My own brain seems to have no
issue coupling functionality to visual design. Yes it's probably less optimal
for novice-to-expert transition than having colour variants, but conversely it
also gives stronger immediate affordance as to what subreddit you're using..

~~~
code_duck
It might depend on one's browsing habits. True, I believe the intention was to
give subs their own identity, as if they were individual websites. However, I
frequently click between subs. The fact is that it's a single website.

I have no question that every study of user interface ever published would
indicate that buttons changing visual appearance, position, or availability
with no predictability several times in a browsing session is a high friction
interface.

------
elagost
This is insane.

The issue's primarily addressing distros and projects that ship their own GTK
themes as default to users, like Ubuntu and Elementary and System76. My wife's
desktop runs Ubuntu, and if something doesn't look right, she doesn't even
know she's running something called GNOME - she just knows that the problem is
with software (OS, desktop environment, kernel, video drivers, GTK style
sheet, whatever).

Most people aren't going to blame GNOME for broken style sheets, they'll be
blaming the creator of the style sheet, whether they know what GNOME and GTK
is or not.

------
finchisko
Electron app developers arise :). You don't have distro theming issues, do
you? :D

And now seriously. If linux developers turn away from native ui libs (like KDE
or GNOME), this might be one of the reasons. The other option is specifically
ban disrespectful distros in the license terms.

I strongly believe in freedom (but not as GNU - absolute user freedom).
Freedom IMO should be on both sides. If app developers doesn't want his/her
app to be themed, then we should respect that. Our freedom is too look
somewhere else to satisfy our need.

------
traverseda
It sounds like GTK theming is broken.

------
anotheryou
Leave me my icons.

Meh about the in-app theming. Probably should not be bundled, but sadly most
OSS ist lacking in the front-end and can really use some polish.

------
faissaloo
On the contrary, I think GNOME allows people too much freedom to theme and it
opens the system up to really broken theming. One of the things I love about
Serenity OS is that it has one simple theming engine so everything looks the
way you'd expect between applications.

~~~
anoncake
> On the contrary, I think GNOME allows people too much freedom

Freedom is kind of the point of free software.

~~~
faissaloo
The ability to run what you want and modify what you want is different from
design freedom.

~~~
anoncake
Indeed. Keeping people from modifying their software affects only developers,
keeping people from choosing a theme affects every user.

The ability to use what software you want, however, isn't much different from
the ability to use what theme you want.

And ultimately, freedom is not specifically about running the software you
want, or about modifying software, but about _doing what you want_.

~~~
faissaloo
The ability to use whatever theme you want has created a situation where Linux
UI is in complete disarray. If you want a different UI you should obviously
have that option, but there isn't a major UI system that takes the opposite
approach, instead developer effort is being wasted on a feature that's always
broken all the time and restricted to handful of working themes anyway.

~~~
anoncake
> there isn't a major UI system that takes the opposite approach

Good thing there is at least one then. Blindly cloning other "major UI
systems", now that would be a waste of developer resources.

------
anoncake
> 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. Consistency is more important than
your "brand".

> Appstream Screenshots (the screenshots used in GNOME Software or Flathub)
> are not very useful if they look nothing like the real app does once you
> install it.

> User Help and Documentation are similarly useless if UI elements on your
> system are different from the ones described in the documentation.

Nonsense. Theming doesn't affect the layout of a program. If people were that
bad at abstraction, then how do they recognize they can sit on a metal chair
if they are familiar with wooden ones?

> They are built and tested for the upstream GNOME stylesheet, icons, and
> fonts, so that’s what they should look like on peoples’ systems.

No. They should look like the user chooses them to look. One way for the user
to express their choice is to choose a distribution whose theme they like.

> Changing third-party apps without any QA is reckless, and would be
> unacceptable on any other platform.

∀x. x without any QA is reckless.

~~~
cuddlecake
Your entire comment feels awfully dismissive and egocentric.

The author presents valid and sensible issues with the state of theming on the
GNOME platform. And the overarching topic is essentially User Experience.

Even the slightest change in color can introduce friction between UI elements.
Or to be more extreme, if a theme turns your entire app into a white blurry
mess, you would get mad at the application, and not the theme. Although many
of the same design principles are used in the making of either a chair or a
graphical user interface, they are definitely not the same in any regard.

On the topic of icons: just like language, they evolve over time. On top of
that, icons can have different meaning depending on your background. Icons can
be combined to form a composite icon, and now imagine one of those icons is
not displayed as you intended it to be. The entire meaning can change because
the design intentions are lost.

On the topic of branding: it's not about your desktop being a billboard. It's
about being able to recognize the brand across different operating systems,
and it's also - more or less - the only thing about the product that is not
designed for the purpose of user experience (but in a sense, they still are).
And let's be honest: most apps we use in our day to day life have very tame
brands and adhere to certain standards. That is because the apps we use are
usually good, and we throw the bad, obnoxious ones away really quickly.

All in all, the author presents valid concerns, especially if you don't
project them on how you prefer your UI, but rather, how potential Linux /
GNOME users could have additional difficulties because of theming issues.

~~~
NeedMoreTea
The only egocentrism I see is all in the pompous article requesting that users
do not make perfectly reasonable choices on their own computers. Then attempts
to justify on some absurdly contrived grounds. Neither reasonable _nor_
sensible.

Imagine if Apple asked users not to apply stickers to their laptop as it
denies Apple the possibility to control their brand, or could make the laptop
look broken, even unusable - shock I may even apply a sticker that shows a
broken circuit board or simulates cracked aluminium. Apple's view is that
applying a sticker to the case or keyboard render Appley documentation useless
as they don't look like the pictures we screenshotted in moments.

> Even the slightest change in color can introduce friction between UI
> elements

Yeah, and? They might be the difference between unusable discomfort and
usable, or allow ageing eyes to cope with arrogant and restricted developer
choices, or missing sense of aesthetic. You might not like the colour car I
buy or the decorating scheme I choose for my house. Mind your own damn
business.

> On the topic of branding

Yeah, about that. It's branding that has led computer and phone makers to give
_highly_ limited theming capability. Firefox or my desktop is no longer my own
to adjust and fiddle to unusability (sic) or perfection - _as I see fit._ Like
the paint I use inside my house, mind your own damn business. I might LIKE my
phone, Windows box and Linux box to all look highly distinct from each other
for my own personal reasons. Mind your own damn business.

It is not another surface on which to stimulate my neurons to be further
programmed by the brand. Baa.

Edit: Specifically on icons, I have been changing icons since the days of
Workbench 1.3 in about 1986 or 87. I won't stop now. I've chosen _wildly_
different icons for some apps at times - because they worked better for me.
Icons as space for a logo is an entirely negative fashion to my mind as I
prefer a hint, however vague, of what that a rarely used app does.

~~~
detaro
It _EXPLICITLY_ says that it does not talk about users changing things on
their machines, but wants it to be something the user sets instead of a distro
applying by default.

~~~
NeedMoreTea
I may choose a distro that specifically looks a certain way - like the one
that tries to look just like MacOS. That's a perfectly reasonable thing to
want to do. Just as it's perfectly reasonable to regret consistency on a
platform that doesn't have distros - as you may want to vary.

"However, if you change things like stylesheets and icons, you should be aware
that you’re in unsupported territory."

Unsupported territory, for changing a desktop icon, or adding a higher or
lower contrast stylesheet? Wow. That's pompous and absurd for me. Doesn't
sound like it's explicitly made a reasonable exception though, just piles on a
layer of entitlement for a damn brand.

~~~
darsnack
If a distro is committed to modifying the style sheets to look like macOS,
then it should be the distro’s responsibility to maintain the applications.
Precisely because the distro market for Linux is so varied, it is hard for
Gnome app developers to support all possible theme configurations.

Read the banner at the top of the page again. It doesn’t ask users to stop
customizing, and it doesn’t say there shouldn’t be distros with custom
theming. It just asks distros to stop shipping broken apps as a result of
theming, and it asserts that if that’s the route you want to go, then you are
on your own.

~~~
anoncake
> it doesn’t say there shouldn’t be distros with custom theming.

Reading carefully between the lines, I think they actually do hint at that:

> Please don’t theme our apps

> This is why we ask respectfully that our applications not be themed.

> On a platform level, we believe GTK should stop forcing a single stylesheet
> on all apps by default.

> If you are a distribution who changes the system stylesheet and icons,
> please reconsider this decision.

> If you do, we ask that you please stop theming our apps.

------
taosx
As an end user I never had any of the mentioned users. On some rare occasions
when the state of my distro was probably too unique, I had some problems, but
that's why I use linux.

------
huxflux
Don't theme, well then start to hire/team along with proper designers then
(graphical/UI/UX).

------
thanatos_dem
Please make Linux apps less ugly. The visual design is always a decade behind
mainstream OSes.

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

Yeah so, this is bullshit. Why would anyone have any say what my computer
looks like.

------
781
Write the app in Electron. Problem solved. No more OS overriding your look.

~~~
Legogris
I can see why the Electron-haters are downvoting you, but you're completely
right. Don't build your apps in GTK if you don't want to have overridden GTK
configurations affect your UI. I would really like Electron to add an on-by-
default standard interface to override CSS rules for Electron apps, though.

(I don't have a horse in the Electron-is-great-or-crap race)

~~~
anoncake
This is about free software. If a distribution insists on theming your
Electron app, it can do so.

~~~
Legogris
Sure. Even if I disagree with the letter, no one has asked for disallowing
distros to do anything - it's more of a plea than a demand.

~~~
anoncake
True. It even explicitly says that they don't want to use a technical solution
like 781 proposed.

------
swiley
This guy probably would have gotten an actual discussion if he had worded his
argument a little more friendly.

