[HN Gopher] The Joy of Linux Theming in the Age of Bootable Cont...
___________________________________________________________________
The Joy of Linux Theming in the Age of Bootable Containers
Author : dopple
Score : 93 points
Date : 2025-04-20 13:56 UTC (9 hours ago)
(HTM) web link (blues.win)
(TXT) w3m dump (blues.win)
| OsrsNeedsf2P wrote:
| Sometimes I wonder why there isn't more enthusiasm around
| theming. Chicago95[0] is popular, but I also love how Garuda[0]
| themes KDE. There's some small websites for downloading themes on
| various DEs, but most of them are a bit jank and it seems built-
| in support beyond basic things like accents aren't there.
|
| [0] https://github.com/grassmunk/Chicago95 [1]
| https://garudalinux.org/editions (screenshots don't do it
| justice)
| wlesieutre wrote:
| Because it always works well for like two applications and
| everything else looks half assed
| seba_dos1 wrote:
| That's how it works in GNOME, yes.
| amarant wrote:
| I used to really enjoy theming and Riceing, but then I realised
| it was pointless: my monitor always looks the same, with a full
| screen IDE window covering up all my fancy themes
| keyringlight wrote:
| I think that speaks to another aspect, individual apps taking
| full control over how they're presented instead of inheriting
| whatever framework the DE is providing or the cohabitation of
| various KDE/QT/GTK/X/other, or electron framework defaults.
| Over on windows even when uxtheme skinning was in full swing
| it was the start of applications doing it themselves (winamp
| and quicktime come to mind), but I have the impression
| developers doing so made sure the extra effort had a payoff.
| WD-42 wrote:
| 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.
| cosmic_cheese wrote:
| 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 there was something of a disinclination away from
| paramaterization in the GTK dev sphere too, which is another
| significant problem for third party themes and accessibility.
| Hardcoded fonts, colors, etc makes for pointless brittle
| rigidity.
| WD-42 wrote:
| 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.
| cosmic_cheese wrote:
| Yeah I recall having to install engines for some themes.
| One of them was murrine I think?
| ChocolateGod wrote:
| 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.
| Vilian wrote:
| The upsude is a more stable applicationand less headaches for
| the developers
| gnomeluvscorpo wrote:
| 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 group of people.
|
| Gnome team, what they did and what they still want to do,
| their attitude towards users - especially those who dare to
| criticize them is THE result of polluting FOSS with corporate
| style of software development.
|
| Theming and customization of Linux is half-dead because of
| what happens at Gnome.
| Mountain_Skies wrote:
| Chasing after The Year of Linux on the Desktop is the
| community's great white whale. The thinking seems to be
| that if Linux can be made to look enough like the major
| mainstream OSes, the masses will flood into Linux and the
| people who lead them there will get to be the heroes of the
| day. Problem is the mainstream OSes make UI decisions for
| many reasons, and the end user often isn't the main
| concern. Linux could, and in the past did, make itself the
| OS of user empowerment and choice instead of being a
| watered down version of whatever is in fashion with the PMs
| at Microsoft, Apple, and Google.
| aecsocket wrote:
| 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
| cosmic_cheese wrote:
| 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
| aecsocket wrote:
| Interesting, I didn't know there was a theming presence
| on OS X! I agree with you in that consistency and
| themability can exist together (and I suppose your
| example proves that), and that had GNOME decided to
| prioritize themability we could have had something like
| that on the Linux desktop. I suppose this is a question
| of priority and where to allocate effort, rather than
| what is technically possible and not. Building a UI
| framework and HIG is already not an easy task, and making
| it customizable in the way you describe would be an even
| bigger burden on developers - many of which are, I
| assume, doing this work for free. But admittedly I
| haven't looked much into GNOME's funding or
| organizational structure, so maybe they _are_ capable of
| it, but just haven 't bothered.
| badsectoracula wrote:
| > 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.
| aecsocket wrote:
| Yeah, I should have clarified that by "your desktop" I
| mean "your GNOME desktop" - i.e. "if you run GNOME, it'll
| look good no matter your preferences". But wrt "your
| desktop" - even if I wanted to, I couldn't guarantee that
| my app looks good on your desktop specifically, because I
| have no clue what your desktop looks like! Which is why I
| want to target a large common denominator of desktops
| instead, where I know it can look good.
|
| The counter argument to that is "so let the user theme
| the app, to suit their own desktop", which would be a
| decent solution, but:
|
| 1. My vision for my app might conflict with your vision
| for your desktop. Maybe I want this button to be a light
| blue because it meshes well with some other elements in
| the app, but you want it to be a darker blue because it
| fits with your desktop's color scheme. What happens then?
|
| 2. This still doesn't guarantee that the app will look
| good. If you theme my app's home page, but don't theme
| the rest of the pages, then sure it'll look good at the
| home page - but as soon as you start using it, the look
| will fall apart. Or, what if I push an update to my app
| which adds a new page with a new kind of UI element? Do
| you really want to be maintaining your desktop theme for
| every single app you have?
|
| 3. This adds a burden on me as the developer to make
| parts customizable. This is the least convincing argument
| in this list IMO, since if there was better tooling and
| infrastructure for theming in GTK this wouldn't be a
| problem - but there isn't, so it is still a problem.
|
| As a practical example, my app makes use of a WebViewGTK
| to display some info. I inject some custom CSS into this
| web view to make it look like Adwaita. This touches on
| points 2 and 3:
|
| 2. The webview has some UI widgets which aren't present
| in the rest of GTK, like a sticky header bar. You would
| have to manually maintain a stylesheet for this single
| element.
|
| 3. I now need to write a way to let users theme the
| custom CSS inside the webview, rather than just the CSS
| of the GTK widgets themselves. (I _have_ already written
| this, but it 's still a maintenance burden.)
| JCattheATM wrote:
| > My vision for my app might conflict with your vision
| for your desktop. Maybe I want this button to be a light
| blue because it meshes well with some other elements in
| the app, but you want it to be a darker blue because it
| fits with your desktop's color scheme. What happens then?
|
| The user trying to make your app match their desktop
| should 'win'. Your responsibility is to ship out an app
| and make sure it works in the way you want it to work.
|
| If the people need to do more work to make it look good
| on their desktop (as I likely would running awesoemwm),
| that shouldn't be prevented, but it also need not be
| encouraged. It should at the least though be facilitated,
| certainly to a better extent than it is.
| zzo38computer wrote:
| I think there are many problems with GNOME and GTK. Some
| programs require GTK, but other than that I avoid them when I
| can. The theming is not the only problem, but it is one of
| them.
| undeniablemess wrote:
| Interesting. Didn't know about bootable containers.
|
| I guess the equivalent in the NixOS world would be its
| impermanence module, which erases root on every reboot to keep
| things as stateless as possible.
| danieldk wrote:
| I think most bootc-based systems keep /etc, /var and others.
| So, it is more like Nix without impermanence where you can
| atomically change/update/rollback your system, but keep some
| system state.
| sabslikesobs wrote:
| Great, original article. I didn't notice at first that this
| blogger is the very same author behind Blue95:
| https://github.com/winblues/blue95
|
| I used to love theming my desktop environment, but the joy faded
| when I realized the UI felt much more magical than anything I was
| using it for. Wonderful application of the tech, though.
| pipes wrote:
| Never seen blue95 before, that is really nice.
| JCattheATM wrote:
| I think ZFS snapshots, or whatever the brtfs equivalent is, makes
| a lot more sense than using containers just to experiment with
| theming.
|
| I also don't think the distinction between distro and container
| is murky at _all_.
| kayson wrote:
| 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 package versions
| in the release notes[2], but I wonder if anyone actually reviews
| it before release. All it takes is one vulnerability in one repo
| / package and you can enjoy your new cryptominer.
|
| There's something nice about running Debian and having confidence
| in all the packages because they're built and maintained by the
| Debian team. Of course there are exceptions, but in my experience
| they're rare. The only non-standard repo I regularly use is fish
| shell, and the updates are so few and far between (and very
| public) I think the risk is low.
|
| I suppose this isn't strictly a container-specific problem; you
| could add the repos and install / update all those packages
| yourself too. But being able to package everything up into a
| single file that you can then boot into as your OS means you're
| also packing all the supply chain risk.
|
| Curious if anyone else shares my concern or if I should just put
| my tinfoil hat back on...
|
| 1. https://github.com/ublue-os/bazzite/blob/main/Containerfile 2.
| https://github.com/ublue-os/bazzite/releases/tag/42.20250417
| danieldk wrote:
| 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.
| kayson wrote:
| Yeah I think that may be what I end up doing.
| moondev wrote:
| > 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
| kayson wrote:
| 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.
| nickjj wrote:
| 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 enables being able to do full end to end tests in about 5
| minutes. The container spins up in 1 second, the rest is the
| script running its course. Since it's just a container you can
| also use volume mounts and leave the container running in case
| you want to incrementally test things without wiping the
| environment.
|
| Additionally it lets folks test it out without modifying their
| system in 1 command. Docker has enabled so many good things over
| the last 10+ years.
| gbraad wrote:
| 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.
| trollied wrote:
| This made me think, I used to love playing with Enlightenment
| back in the day. It was really trying to push what X11 could do.
|
| Surprised it's still going https://www.enlightenment.org/
| qwerty456127 wrote:
| I am actually surprised how bad the actual state of the art is. I
| would expect modern OSes to be infinitely and easily themable and
| a thriving scene of OS theming to exist (and offer perfect retro
| revival themes alongside completely original and loosely inspired
| ones) but it apparently is not the case at all.
| dicytea wrote:
| bootc would be more attractive for this theming use-case, if
| there's a 1-line method to spin up a graphical VM straight from
| the docker file.
|
| I looked into it, but it looks like that you need to manually
| build the image and fiddle around with qemu.
| JCattheATM wrote:
| Yeah, a VM or just filesystem snapshots make much more sense.
|
| Containers are so easy so people just started using them for
| every use case, even when it doesn't necessarily make the most
| sense.
___________________________________________________________________
(page generated 2025-04-20 23:00 UTC)