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

The Joy of Linux Theming in the Age of Bootable Containers

blues.win

Post reply on HN
Print view View original

21–30 of 77 posts

Re: The Joy of Linux Theming in the Age of Bootable Containers

#21

Post by WD-42 »

cosmic_cheese wrote: post #8
WD-42 wrote: post #6

Earlier quoted context omitted.

The Gnome/gtk folks have been systematically removing theming capabilities for the last decade+ in the pursuit of an Apple-like philosophy towards ui. This has really killed a lot of theming because so many apps use GTK.

Even before that, GTK app theming was a bit hit or miss, likely because of the way GTK uses CSS for themes. Personally I believe CSS to be quite ill-suited for the purpose. It’s ok if you’re writing a theme for a bespoke one-off app but breaks down in the system theme use case. In particular, CSS inheritance makes for a lot of unnecessary trouble for both third-party themes and accessibility affordances. Last I knew…

Before css there were engines, which were like families of themes. One of them was the pixmap engine which was what it sounds like: it used images to make up elements of the theme. Some of the most ambitious themes used this engine. CSS didn’t come until much later.

Re: The Joy of Linux Theming in the Age of Bootable Containers

#22

Post by kayson »

moondev wrote: post #20
kayson wrote: post #13

I really like the idea of immutable Linux and bootable containers. My next project will probably be switching to bazzite. But I took a look at the Containerfile[1], and I have some big concerns about the fragility of their supply chain. It uses 20 different copr repos (granted, half are their own), and I didn't count how many packages. Best I can tell, none of the versions are pinned. They do dump a diff of all packa…

> Best I can tell, none of the versions are pinned. From your link, everything is pinned? So a theoretical exploit in a future release of package is not going to exist in this immutable release https://github.com/ublue-os/bazzite/releases/tag/42.20250417

Right but everytime a new immutable release is created, it automatically pulls the latest version of every package. It's not a manual change of package versions.

Re: The Joy of Linux Theming in the Age of Bootable Containers

#23

Post by kayson »

microtonal wrote: post #18
kayson wrote: post #13

I really like the idea of immutable Linux and bootable containers. My next project will probably be switching to bazzite. But I took a look at the Containerfile[1], and I have some big concerns about the fragility of their supply chain. It uses 20 different copr repos (granted, half are their own), and I didn't count how many packages. Best I can tell, none of the versions are pinned. They do dump a diff of all packa…

Nothing holds you from using bootable containers in the same way you use Debian and only use packages from the official Fedora repositories, starting from Fedora's bootc base images.

Yeah I think that may be what I end up doing.

Re: The Joy of Linux Theming in the Age of Bootable Containers

#24

Post by cosmic_cheese »

WD-42 wrote: post #21
cosmic_cheese wrote: post #8

Earlier quoted context omitted.

Even before that, GTK app theming was a bit hit or miss, likely because of the way GTK uses CSS for themes. Personally I believe CSS to be quite ill-suited for the purpose. It’s ok if you’re writing a theme for a bespoke one-off app but breaks down in the system theme use case. In particular, CSS inheritance makes for a lot of unnecessary trouble for both third-party themes and accessibility affordances. Last I knew…

Before css there were engines, which were like families of themes. One of them was the pixmap engine which was what it sounds like: it used images to make up elements of the theme. Some of the most ambitious themes used this engine. CSS didn’t come until much later.

Yeah I recall having to install engines for some themes. One of them was murrine I think?

Re: The Joy of Linux Theming in the Age of Bootable Containers

#25

Post by aecsocket »

gnomeluvscorpo wrote: post #11
WD-42 wrote: post #6

Earlier quoted context omitted.

The Gnome/gtk folks have been systematically removing theming capabilities for the last decade+ in the pursuit of an Apple-like philosophy towards ui. This has really killed a lot of theming because so many apps use GTK.

Perhaps with all these changes to GUI since initial Shell release their goal is to enter some niche mobile market and call job done. Because nothing else explains all this interface gutting out they did over 14 years. Once they finish sucking donations and other forms of financial support they'll probably announce it's time to " sunset " Gnome/gtk because it sadly didn't met unspecified expectations of unspecified gr…

This opinion of "Gnome is killing customization" is something I see quite a lot, but which I think people take the wrong way. It's absolutely true that Gnome is designed to be less themeable than other DEs like KDE, or individual WMs - and by extension, GTK apps and apps designed to be used on Gnome are harder to customize/break more when you do theme them. But I disagree that "customization of Linux [being] half-dead" is a bad thing; on the contrary, I support the lack of theming options, and I like that there's someone on the Linux desktop that pushes this hard for consistency.

To make my biases clear: I'm a software developer that uses Gnome daily, and is developing a GTK/Adwaita app. I used to rice a lot back in the i3 days, but I don't particularly care about that nowadays, and stick to the defaults when I can. For my purposes, GNOME and Adwaita is perfect since it's very opinionated by default, and you can make good looking apps with minimal effort. Since all Adwaita apps are supposed to look similar and follow the same HIG, most of my desktop apps have the same look - but more importantly, the developers of the apps can also be confident that their apps look correct on my desktop. This is something that developers in the GTK space generally want, and for good reason[0].

One argument is that you as a user of the desktop should be able to have the final say on how your apps look, which is a totally valid take! And there are DEs, WMs, and apps which give you this freedom like Hyprland. But this doesn't guarantee that those apps will look good, or look consistent with each other, or even act consistently across apps. On the other hand, I as an app developer want to guarantee that my app looks good on your desktop, and the easiest way to achieve that is to target a single desktop environment, rather than an infinite combination of possibly-similar-but-maybe-completely-different desktops. Every preference has a cost[1][2], and when you take this philosophy beyond just preferences and expand it to color schemes, padding, margin, iconography, typography, it becomes unmanageable.

This isn't to say that GNOME is perfect, and I disagree with the project on some fundamental technical things like not supporting xdg-layer-shell[3], and refusing to accommodate server-side decorations for apps which don't want to render decorations themselves. (On the cultural side I can't comment, since I have no experience with that.) But in my opinion, this is the project that can deliver a usable and consistent Linux desktop to the average person the most effectively.

[0]: https://stopthemingmy.app/

[1]: https://blogs.gnome.org/tbernard/2021/07/13/community-power-...

[2]: https://ometer.com/preferences.html

[3]: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1141

Re: The Joy of Linux Theming in the Age of Bootable Containers

#26

Post by cosmic_cheese »

aecsocket wrote: post #25
gnomeluvscorpo wrote: post #11

Earlier quoted context omitted.

Perhaps with all these changes to GUI since initial Shell release their goal is to enter some niche mobile market and call job done. Because nothing else explains all this interface gutting out they did over 14 years. Once they finish sucking donations and other forms of financial support they'll probably announce it's time to " sunset " Gnome/gtk because it sadly didn't met unspecified expectations of unspecified gr…

This opinion of "Gnome is killing customization" is something I see quite a lot, but which I think people take the wrong way. It's absolutely true that Gnome is designed to be less themeable than other DEs like KDE, or individual WMs - and by extension, GTK apps and apps designed to be used on Gnome are harder to customize/break more when you do theme them. But I disagree that "customization of Linux [being] half-dea…

Much of the frustration inspired by GNOME/GTK’s unthemability comes down to not having a few very simple knobs for users to tweak. Point in case, one of the primary reasons I used to theme GNOME desktops was to clean up Adwaita’s padding, which is utterly egregious for desktop usage. If GNOME just had a padding slider with 3-5 notches that’d go a long way and wouldn’t impair developers’ ability to build consistent apps in the least. Affordances like these are rarely given however and have to be fought for.

Aside from that, consistency and themability are not at all mutually exclusive. Back in the early days of OS X, theming by hacking system resource files (or patching them in memory via haxies[0]) was quite popular and for the most part, worked very well — generally, the only apps that didn’t play nice with themes were those sitting in the uncanny valley between native and custom, using bits of both, which tended to not be the highest quality applications anyway. This was way before Apple started pushing devs to parameterize their apps, too, and so similar theming capabilities today would work even better since themes can just tweak the parameterized fonts, colors, etc as needed to maintain coherence and usablity.

The real problem with GNOME/GTK is simply that it wasn’t designed with user customization in mind even as a remote possibility. A UI framework that did keep these things in mind combined with a strong dev culture of parametrization would make for a desktop that’s both customizable and consistent.

[0]: https://en.wikipedia.org/wiki/Unsanity

Re: The Joy of Linux Theming in the Age of Bootable Containers

#27

Post by badsectoracula »

aecsocket wrote: post #25
gnomeluvscorpo wrote: post #11

Earlier quoted context omitted.

Perhaps with all these changes to GUI since initial Shell release their goal is to enter some niche mobile market and call job done. Because nothing else explains all this interface gutting out they did over 14 years. Once they finish sucking donations and other forms of financial support they'll probably announce it's time to " sunset " Gnome/gtk because it sadly didn't met unspecified expectations of unspecified gr…

This opinion of "Gnome is killing customization" is something I see quite a lot, but which I think people take the wrong way. It's absolutely true that Gnome is designed to be less themeable than other DEs like KDE, or individual WMs - and by extension, GTK apps and apps designed to be used on Gnome are harder to customize/break more when you do theme them. But I disagree that "customization of Linux [being] half-dea…

> I as an app developer want to guarantee that my app looks good on your desktop

When your app doesn't follow how my desktop looks it doesn't look good on my desktop. And unsurprisingly most modern Gtk3 and especially Gtk4 apps do not look good on my desktop.

What you actually mean here is that you want to guarantee that your app looks good on your desktop, not mine.

Re: The Joy of Linux Theming in the Age of Bootable Containers

#28

Post by ChocolateGod »

cosmic_cheese wrote: post #8
WD-42 wrote: post #6

Earlier quoted context omitted.

The Gnome/gtk folks have been systematically removing theming capabilities for the last decade+ in the pursuit of an Apple-like philosophy towards ui. This has really killed a lot of theming because so many apps use GTK.

Even before that, GTK app theming was a bit hit or miss, likely because of the way GTK uses CSS for themes. Personally I believe CSS to be quite ill-suited for the purpose. It’s ok if you’re writing a theme for a bespoke one-off app but breaks down in the system theme use case. In particular, CSS inheritance makes for a lot of unnecessary trouble for both third-party themes and accessibility affordances. Last I knew…

GTKs CSS engine is great for app developers because it's powerful and easy. You can make something look slick with little work.

But its terrible for themers, it's like running a CSS override on every site that runs Bootstrap and expecting it to work properly. It won't.

I don't run any themes anymore so it doesn't bother me.

Re: The Joy of Linux Theming in the Age of Bootable Containers

#30

Post by gbraad »

nickjj wrote: post #15

Regular containers also happen to work great for testing dotfiles. Many years ago I added an install script to https://github.com/nickjj/dotfiles to get set up in basically 1 command because I wanted a quick way to bootstrap my own system. I used the official Debian and Ubuntu images to test things. Over the last few days I refactored things further to support Arch Linux which has an official Docker image too. This e…

No place like ${HOME} https://dotfiles.gbraad.nl ;-). I went further and generate images to easily spin up development environments, based on bootc vms or containers.

Never stop tweaking. No computer can be called home until it runs your own set of aliases/commands.

Post reply on HN