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

31–40 of 77 posts

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

#31

Post by aecsocket »

cosmic_cheese wrote: post #26
aecsocket wrote: post #25

Earlier quoted context omitted.

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 ap…

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.

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

#32

Post by aecsocket »

badsectoracula wrote: post #27
aecsocket wrote: post #25

Earlier quoted context omitted.

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.

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

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

#33

Post by qwerty456127 »

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.

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

#35

Post by pipes »

sabslikesobs wrote: post #9

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.

Never seen blue95 before, that is really nice.

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

#36

Post by JCattheATM »

dicytea wrote: post #34

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.

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.

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

#37

Post by JCattheATM »

aecsocket wrote: post #32
badsectoracula wrote: post #27

Earlier quoted context omitted.

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

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 c…

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

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

#38

Post by bagatelle »

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…

Just glancing through your dotfiles, I was wondering why you use VcXsrv. WSLg has always been fine for me, and I've never heard of anyone trying to use a different X server.

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

#39

Post by cosmic_cheese »

aecsocket wrote: post #32
badsectoracula wrote: post #27

Earlier quoted context omitted.

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

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 c…

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

Probably something similar to how Apple platforms handle colors. Instead of providing a single static light blue, you have a couple options:

1. Use a “system color”, which is pre-tuned for optimal contrast, appearance, and usability and adjusts automatically when e.g. the user switches between light/dark mode or enables an accessibility setting related to color or vision

2. Define a light blue that’s actually multiple variants of the color bundled together, with each being optimal to various environments, with the UI framework choosing the right one depending on the situation

Arguably developers should be doing these things anyway for accessibility reasons. It’s not been good practice to use e.g. bare color hexes for quite some time now.

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

#40

Post by XorNot »

kayson wrote: post #22
moondev wrote: post #20

Earlier quoted context omitted.

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

I mean that's the big lie isn't it? We all know no one is actually looking at these.

Every system which tells me how immutable it is then shows me it's automatic version bump script or something.

Post reply on HN