3 ms·
I’ve not actually built any themes so take these thoughts with a grain of salt, but my impression is that with GTK at least, most of the problems come down to C
by cosmic_cheese 2y ago
I’ve not actually built any themes so take these thoughts with a grain of salt, but my impression is that with GTK at least, most of the problems come down to CSS conflicts and libadwaita doing its own thing separate from GTK proper. It seems like a lot of GTK apps hardcode colors, fonts, etc instead of parameterizing too, which means they aren’t going to respond to theme changes correctly. All together these combine to produce a pretty spotty theming experience.
Things seem a bit better on the Qt side of things, but it suffers resolution scaling issues. Most KDE/Qt themes I’ve tried can’t draw correctly at non-integer scales.
Personally I think that CSS is actually pretty badly suited for the use case of desktop UI toolkit theming. It’s fine for one-off apps but quickly becomes a mess when it needs to be part of a larger more flexible system.
- TingPing 2y agoIts just an impossible problem. Apps like to make very custom interfaces. All of CSS is great. Platforms like consistency, so they maintain their own complex CSS. Users like to customize everything, so CSS is powerful but will always break as its fighting the others.
- cosmic_cheese 2y agoMore than apps liking to make custom interfaces, I think it’s more that companies like to try to make their UI into a brand, necessitating a high level of customization. If you look at the majority of FOSS software, even much of it that’s held in better regard by users (e.g. Krita), highly custom UI is considerably more unusual. There’s not much that can be done about UI-as-branding unfortunately, but for everything else I believe that parameterization is the answer. Don’t hardcode colors, fonts, etc and instead favor framework-provided presets (like UIColor.systemBackground and UIFont.caption1 on iOS) wherever practical and that’ll for the most part make your app remain usable regardless of how the user’s themed their system, short of just using a badly made theme. This should be done anyway because it’s a huge boon to accessibility if the user can e.g. enable colorblind mode and have the reds and greens in apps adjust automatically because their devs were thoughtful enough to use Color.systemGreen and Color.systemRed instead of hardcoding #FF0000 and #008000.
- TingPing 2y agolibadwaita does this to a degree: https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1.6/css-variables.html https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1.6/css-...
- rendaw 2y agoI'm working on some Gtk/desktop stuff and keep coming back to the Gtk/Gnome/Wayland bug trackers where the Gtk people are constantly stonewalling ecosystem improvements. Urgency notifications, disabling client-side decorations, themeing, etc. Stuff like "well some programs put stuff in the titlebar, therefore we can't allow a hint for the ones that don't". The Catpuccin theme is very popular and they recently threw in the towel, just for the Gtk port. I don't know if Qt is better but I've heard about 0 drama from them... I made a poll on reddit though and for some reason people (users) still prefer Gtk to Qt.
- cosmic_cheese 2y ago> I don't know if Qt is better but I've heard about 0 drama from them... I made a poll on reddit though and for some reason people (users) still prefer Gtk to Qt. I think this is probably because GTK programs tend to sport UI designs that are nicer/friendlier and less “designed by a programmer”, even if they skew overly simple. Qt leans the other direction, with apps that are generally complete from a technical standpoint but have a good deal of room for improvement in UI design. Incidentally I think this is also why distros centered around GTK-based DEs still dominate.
- badsectoracula 2y agoI'm pretty sure the reason for Gtk being way more common than Qt has more to do with inertia (way in the past Gtk's license was more desirable and wasn't until Qt4 that changed, so any programs before or around that time that were made in Gtk remained in Gtk even after Qt4) and language availability. Specifically for the latter, C is much easier to make bindings for and GObject provides functionality for doing it automatically, thus Gtk is available in many more languages whereas Qt's use of C++ is much harder to both make bindings and do it automatically. The end result is that Gtk is simply more widely available and so much more likely to be used by someone who doesn't want to use C or C++ (the main exception seems to be Python which has official high quality bindings for C++). The UI designs are just a byproduct, there is nothing about Qt that makes it hard/impossible to have Gtk-like designs, but since Gtk is used by a lot of programmers, when encountering a program like those you mention, the chances are higher that it is written in Gtk than in Qt because more programmers use Gtk than Qt. (note that this is specifically about Linux desktop applications, i think overall Qt is used more than Gtk outside Linux)
- asystole 2y agoGTK theming was a mess long before libadwaita came along.
- d3Xt3r 2y agoIt's no secret that the GNOME/GTK guys _hate_ theming. So much so, that made an entire website for it: https://stopthemingmy.app/ https://stopthemingmy.app/
- jeroenhd 2y agoThe theming they dislike isn't the theming their users are doing. Their biggest issue is distros packaging their own theme, which can easily break an entire suit of applications without the user knowing it's because their distro decided to override the colours or mess with widths. As the page you linked says: > 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. Theming Gnome by editing the default style sheet is akin to distro theming the web by modifying Firefoz's default style sheet. Tons of websites will break in weird and interesting ways but the user won't know to blame the distro, because they never touched user.css or even know it's possible to change the default. The same breakage also happens on KDE and Qt applications (and more, I have seen Eclipse launch with black text on a black background when dark mode is enabled) but the developers don't seem to care as much, or are less bothered by the false bug reports. I've also experienced the "this doesn't look anything like the screenshots" feeling because of the theme I have applied, but at least I know it's my own fault.
- sham1 2y agoTo be fair, this one is specially to address the issue of a distro theming an app, breaking it, and that leading to a bug report at the upstream even though it's the distro at fault. If a user is willing to take responsibility for breakage and such, then I'm not sure the devs are against theming as such. > 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.