Follow

2011: "What if we ported our UI to javascript? Then we get CSS theming for free!"

2019: "Our incredibly fragile tools only work with one micromanaged theme nobody likes. Please take systems integration advice from webshit design nerds because branding"

stopthemingmy.app/

- via @ngate@twitter.com

@sir
> denies the developer the possibility to control their brand

and rightly so.

If a developer cares more about their brand, and their app having the same UX for everyone, instead of providing the users (and distros which act as a proxy for their users) with building blocks they can use to make a coherent system, then that developer is doing something wrong.

@Wolf480pl @sir what the fuck is brand doing in FLOSS software anyways? Isn't FLOSS all about being able to use software *however you fucking want*? Aren't brands for corps and not for communities?

The very premise behind the page makes me angry.

@jellypotato @Wolf480pl no one does "alienate your own community" better than GNOME does

@jellypotato @sir
Well, in a way, you have a brand whether you like it or not.

For example, if someone tells you "Kdenlive sucks and keeps crashing", you don't know which version of Kdenlive that person was running, on which distro, with which versions of libraries, and how much the distro patched Kdenlive. So the opinion of "sucks and keeps crashing" attaches itself to the implicit "Kdenlive" brand, whether Kdenlive developers want such brand to exist or not.

@jellypotato @sir
Well, technically you can avoid creating a brand by giving your project an extremely uncatchy name that nobody will remember or bother to pronounce, but that makes it difficult for people to talk about your project in general...

@Wolf480pl @jellypotato @sir Also there's an expectation that we give our apps a name and logo, the application menus require it. This, together with the app's reputation forms as much of a brand as any company.

@jellypotato @sir @Wolf480pl What browser do you use? Whatever name you come with, it's a "brand'". Why do you like that browser better than Internet Explorer?

... unless you like IE the most ;-)

Regarding community, companies can also build communities. Not each their own community but among them, while competing: Red Hat, SUSE, Canonical and many many others collaborate to one the most impressive kernels in history and any improvement benefits them all.

@Wolf480pl @sir I can certainly understand that other apps have a harder time dealing with themes than I do and as such they may well be right to push distro to take theming as a more serious endeavor.

But I find it's my role to say "they don't represent all GTK developers". Because I want Odysseus to be able to work with other themes, and in my case the theming issues don't seem to be too bad.

And I seriously don't care that much about branding, it's just something I had to do.

@Wolf480pl @sir My argument is, that a developers time is valuable no matter what. It's not about some dev picking some GTK theme and running with it, the dev designed what he made in the best possible way he could, which means functional, modular and simple. To have some distro slap some eye candy overtop of something you worked so hard on, that ends up causing your program to not function correctly amd then having a flood of users filling bug reports for bugs that don't exist and especially with the way some people treat others, it's a little bit discouraging.

@trash @sir
Yes, the problem is exactly that users blame (report bugs, complain about, un-recommend to other users) the upstream, instead of blaming the distro.

However, I think makinf it easier for the upstream devs to control their brand would not help here.

But how about we do the opposite: disconnect the downstream versions of the application from the upstream brand, and connect it with the distro's brand instead?
Sth. like Debian's IceWeasel.

@trash @sir
Actually, that's more of a workaround than a solution.

In an ideal world:
- GTK would have a better support for themes, so that apps work well with different themes in general, unless the app dev goes out of his way to make his app break
- distro package maintainers would ensure that the package they maintain works well with distro-provided themes
- users would know to complain to the distro package maintainers first

Hm... maybe just one of the above would be enough?

@sir gtk stylesheeting seems to be a mess, but freaking out about icon themes and custom app icons is just bizarre

@sir
Damn I didn't read something this stupid since so long it's worth loosing time replying.

- GNOME did port anything to JavaScript besides parts of its documentation, and there was no plan to do otherwise.
- The UI toolkit is GTK, hence C.
- How is JavaScript in *any* way related to CSS? One is a programming language supported by GObject Introspection, the other is a style sheet language that GTK 3 uses to implement its theme and that apps can use to extend the theme.

@sir
- CSS was and still is a right choice: it's a well defined specilized language that which benefit theme maintainers greatly, there is no point reinventing the wheel.

@sir
- When you develop an application you very often have to create new specilized widgets, and sometimes you need to style and the styling machinery may not provide all the tools you need, so you have to adjust your custom style extensions to the themes you are targetting. You can't support all the themes the next season's fashion will make distros ship by default.

@sir
- When distros change the default theme and force it onto apps, they effectively change the SDK the apps have been developped for. The apps have not been tested and developped for and tested against that modified SDK, making the distros responsible for verifying that the apps are still working as expected to ensure their users will have a decent experience.

@sir
- Breaking apps downstream and sending issues upstream to fix our downstream quirks is a no go. Sending our users to complain upstream is even worse.

Also: please don't call some of the finest developers and designers I know "webshit design nerds". If you don't understand an issue, STFU, lurk moar, and don't insult persons who actually studied an issue and try to fix a broken status quo.

@KekunPlazas do you feel better now, after ranting 6 posts into my notifications in response to a joke

@sir
I don't like Adwaita either, but I stay away from random themes. I only use popular ones like Adapta - which l just realized is looking for maintainers now. Adwaita is either too bright or too dark.

I know it might be unfair for GNOME's developers to maintain more than one themes. Many themes can break KDE Plasma's appearance, but to their advantage they have a good default theme: Breeze.

@KekunPlazas @sir

Status quo:

1) GTK haven't manpower to maintain theming API (or is it a decision by design?)
2) Some GNOME developers keep spreading that CSS stylesheet can be used to provide third party themes that users or distro can apply
3) Some GTK apps developers complain for CSS stylesheet abuse

Maybe 1) could be made clear so users, app developers and distro that want theming will know that they have to use another toolkit, like Qt?

Sign in to participate in the conversation
Mastodon

cmpwn.com is a private Mastodon instance for friends of SirCmpwn.