Hacker News Reader

I like Linux because it gives me the freedom to make my system behave how I want. The GNOME devs seem to think that GNOME should only behave how they want. For example, last time I checked, GNOME required a third-party plugin just to move the clock from the center of the status bar to the side.

I'm not at all surprised to see that this mindset extends to GTK.

> just to move the clock from the center of the status bar to the side.

And I like linux because there are plenty of people who also do not care about this and want to just use their computer.

You can "just use" KDE too. The default are actually less insane than gnome, it's easier to use.

The idea that more functionality makes software less usable makes no sense to me. No, it's more usable.

Its like when people argue that iOS not allowing anything other than safari is a good thing.

Okay... how? Because if you like safari, nothing changes for you. You just keep using it. You wouldn't even be able to tell.

Similarly, if you like KDE you can just... use it. You don't actually have to change anything. There's no gun to your head. If you're the type of person who just takes software and uses it, then great - you don't need Gnome for that. KDE is actually better at that, IMO.

Can you do that on Windows/mac?

Gnome devs not withstanding, you have access to the source to change it if you want or put up a PR?

Being able to make a small change is good when every thing is well defined small parts. You can change the part you want and then use everything else as per normal. If everything is so tightly integrated that you end up having to maintain a fork of a large project, it doesn't work out so well.

I don't know which is true for this particular case, but I'd hazard a guess that it is a much bigger task than it needs to be.

I have seen Gnome devs talk of removing features because people were using them the wrong way. Not that people weren't using the features at all, just not for the purpose for which they were written. Experiences like that make me think that pull requests wouldn't get you very far either.

You can look at the code of an extension that does the move, if you want an idea of what the level of effort is: https://github.com/kuvaus/moveclock

You can't put up a PR if the gate keepers reject your whole design approach

As a gatekeeper in an unrelated small project, I understand gatekeepers being selective. You have a vision, design standards, quality standards. Drive-by PRs that add "just this one thing I need" features is how your well-designed, cohesive project becomes a kitchen sink of shit.

> You have a vision, design standards, quality standards.

Unless, of course, all of those are shit, so a more design-competent person can drive by with an improvement, which will be rejected because it's too shiny

Well, yeah. They have their own design approach, if you don't take that into consideration, aren't you the one that in the wrong?

You're not, that depends entirely on the assessment of the relative approaches and whom you care more about, users or a subset of designers closest to the gates.

But that's beside the point, the point was the criticism of the "send a PR" even though that resolves nothing due to the mismatch.

2025, still cannot have taskbar on left or right side in Windows 11.

I can do that on GNOME and macOS. And yes, with 21:9 it is very nice. With a vertical monitor or a 3:2 (Surface), not so much.

You have to install an extension to do that on GNOME, likewise on Windows 11 you can use Explorer Patcher.

Both "monkey patch" the shell.

While I prefer tiling windows manager, GNOME’s approach is sensible. Restrain your features to a restricted default and allow users to extend it if they want to. The code is open and well organized as far as I can see. So it’s very easy to see where to extend from.

Writing Gnome Shell extensions is easy, they're just JS scripts...

If you really need to move your clock with a bunch of clicks, there's also KDE which is less opinionated...

Gnome shell is designed in a way so that users can configure basically everything using plugins. That way everything does not have to go through the Gnome Shell developers and much more specific and esoteric functionality can be added.

> The GNOME devs seem to think that GNOME should only behave how they want.

For many years I followed this whole outrage but wasn't really sure whom to believe because I didn't have any stakes in the matter. Then the GNOME/GTK devs removed support for key themes[0,1] and I still have no idea why. The arguments they brought forward make absolutely no sense to me.

Now I get where people were coming from.

[0]: https://old.reddit.com/r/emacs/comments/c22ff1/gtk_4_support...

[1]: https://news.ycombinator.com/item?id=35702303

Sun donated a bunch of UI guidelines to the GNOME project back in the really early days. Those guidelines basically boiled down to "You users are idiots, and power users don't matter, so get rid of as many options and force a single way of interacting with the software." The GNOME development philosophy just expanded on this.

Oh, I would love it if Wayland provided a standard UI toolkit (server-side)! Is that a thing that happened when I wasn't looking?

No, there are no protocols intended to implement such a thing at this time. I'm not aware of anybody attempting to spec out such a protocol either, but I do think it's a really interesting idea.

Edit: s/protocol/interface

There is about zero chance that Gnome would implement such a protocol which makes the whole endeavor pointless. They can't even agree on server side window decorations.

Server side ui toolkit doesnt make much sense to me. Better idea is to target some multimedia layer like web browser, electron, etc ... Or just hope someone someday comes up with UI library that doesnt suck.

How would this work given that the major DE's have completely different UX and design?

That's precisely the point! It would be really nice for applications to be able to operate agnostic from the DE's decisions about UX and design. Applications want something much more high level: button here, scroll bar there, text input here. It's the DE's job to make such things accessible and look pretty. If you think about it, that's precisely why the web is a popular user interface target: the application has a much higher level interface, and all those concerns are, correctly, handled at a different abstraction layer.

I don’t think it’s possible to build a generic UI across DEs, at least if you actually want them to feel native. They’ve all got different standards, so while Gnome might have a button here, a text box here, and scroll bar there on KDE a scroll bar here, text box here, and then the button might make more sense.

My point is that the application doesn't have to care if it's running in Gnome or KDE. It just speaks Wayland protocol and then it gets a Window and some UI in it. The gnome window manager / KDE window manager then makes that UI properly native.

Consider input methods. That clearly belongs in the window manager process, not each application process. The application should simply ask for a text box, and then receive events when the text in the box changes. The fact that I'm typing Japanese into a fancy UI shouldn't make any difference to the application, other than what text it receives from the widget events.

And that should all be possible in a small, static executable, that is speaking the Wayland protocol, and has zero dependencies other than networking syscalls.

I like the idea but, having built many UIs for many different applications over the years, I doubt it would work for anything non-trivial. The thing is, as soon as your UI reaches a certain level of complexity you need tight control over the look and feel, especially over the positioning of UI components relative to each other. Unfortunately, the latter depends a lot on how exactly your UI components look and behave.

For example, your text input box's label might be displayed to the left of the box, to the top, or it might be one of those floating labels that are displayed inside the box but move to the top border as soon as you focus the box. Depending on that, you would choose the spacing to neighboring text boxes and buttons differently, and maybe also arrange things differently altogether, because of different space requirements.

In other words: Your application would need to know what exactly the Wayland "UI layer" is going to display in order to send it precise instructions. But then your abstraction is very leaky.

> makes that UI properly native

That's five words with unimaginable complexity.

No it is the developer's job to make things be nice and work well. We've gone past pretending to be native shit for pretty much everything. We define our own design styles and language since the web took off.

I don't think we will even see universal support for server-side window decorations in our lifetime, so don't hold your breath ;)

(yes I'm aware of libdecor, but it sucks to have to pull in yet another complex dependency into clients)

While pulling in a library just for window decorations is insane, the same could make sense for a full UI toolkit - after all, that's how standard UI components have worked on e.g. Windows. In a way, Qt can already fulfill that role because by default it tries to adapt to the look and feel of the platform it runs on, including using GTK themes. Too bad that it's a bloated pig without a stable ABI that would allow you to use the system version.

> after all, that's how standard UI components have worked on e.g. Windows

Standard UI components on Windows are in user32.dll, and that's guaranteed to exist on each Windows installation all the way back to Windows NT.

And to just get an empty decorated window all I need to do is call CreateWindowEx() (which will always look consistent), all the rendering inside that window can then be done through one of the 3D APIs.

Same on macOS, I don't need any optional dependencies to create a decorated empty window which I can then render into with Metal.

For that same scenario (3D rendering into an empty window), Wayland only guarantees me a bare undecorated rectangle I can draw into with GL or Vulkan (and I wouldn't be surprised if even that is an optional feature I need to query first lol). And even if both GTK and Qt would be guaranteed to be installed on each Linux desktop system (so that I can pick one of two frameworks to give me a dedorated window, that would be overkill if I just want an empty window for 3D rendering - and even then I don't know if a window created through Qt would look consistent on a GNOME desktop or vice versa).

Of course that topic has been discussed to death without anybody who could fix that problem once and for all (by making the server-side decoration extension mandatory for desktop Linux systems) even recognizing that this is an issue that needs fixing.

Tbh, I don't even understand why desktop Linux needs more than a single Wayland implementation. So much wasted redundant work which could be put into actual improvements.

AFAIK, both KDE and GNOME had an architecture already where they changed only the base layer to adapt to wayland. Wlroot have a different architecture. And that’s why you have three mainstream implementations.

Slightly unrelated, but I wonder why the "Linux desktop maintainers" (whoever that is - and that this is even a question is probably the main problem) haven't come up yet with a minimal shared 'interface library' that's mandatory on each Linux desktop installation, and which provides a standard API (but no implementation) to create a window, get input events and probably also a set of simple UI widgets (buttons, sliders, checkboxes, lists - basically what Win32 or X11 provides).

KDE, GTK or any other concrete UI toolkit register 'drivers/plugins' with this interface library to do the actual work.

Minimal 'framework-agnostic' UI apps can then use this standard shim library and always look fully native, while applications which require the full KDE or GTK feature set can still use those frameworks directly.

Call it Common Desktop Environment or something idk...

I’m not a maintainer, but IMO, it may be the different design systems. Yes there are common elements like buttons and scrolled view. But the whole selling point of a toolkit is consistency, especially around more advanced widgets.

> But the whole selling point of a toolkit is consistency, especially around more advanced widgets.

In theory yeah, but that consistency is out the window anyway when some apps I'm using are GTK, others Qt, and yet others Electron with the JS framework flavour of the week.

A standard shim library which would map to the user's preferred framework (e.g. GTK or Qt) would at least be visually consistent between GTK and Qt - and not just for the window chrome) - even if it only offers a common subset of GTK vs Qt vs ... features.

Why don't the developer do the shim themselves? You can always have a core and shell out the UI to the platform being used. One example is Celluloid [0] (GTK) and IINA [1], both use mpv as their backend. Why not have something like libslack, libspotify (a real one), or libdiscord, then have a more appropriate frontend to meet the users where they are.

[0]: https://celluloid-player.github.io/

[1]: https://iina.io/

...more code in the client that should really be part of the 'operating system', and if I need to do it myself anyway, why should I care about consistency with other applications?

Such an idea only works if it is less work for application developers, not more. And I think the right place for that is the operating system layer, not the application layer.

Yes, but Linux is only the kernel, everything else is someone else project. A distribution is nothing else than a curated list of software projects.

macOS is a good example of what you're proposing. The developer toolkit have a lot of nice frameworks (libraries) to help build apps. But that ties you to Apple. You can't expect consistencies across OS unless someone does the work to provide an intermediate layer, and then you loose on each OS nicest capabilities.

It may not make business sense, but the most elegant solution is to have a core that is your feature set, and then flesh out each dependency according to the platform.

You didn't cover it but is Ghostty still entirely dependent on libadwaita for most of its UI features? I completely lost interest when it was still in beta and I found out many features were disabled on Linux if you didn't want it to look and behave as a Gnome app.

Yes, its a hard dependency. But we go out of our way to add CSS classes to our UI widgets and even have a configuration in Ghostty to supply custom CSS directly (without you having to mess with gsettings or anything). We've seen some pretty incredible customizations in our showcase channel in Discord.

We haven't committed to our CSS classes yet as a stable API but we plan to do that in the next release cycle. Still, they haven't changed much in a year. :)

> CSS classes

GTK has gotten so fat that it's more like a 2nd-rate Electron. Not that Electron would have done Ghostty any good...

I have a bad feeling that the only decent & consistent UI option under Linux is to target Win32 API, then run it under Wine.

What does this have to do with Ghostty?

Are we looking at the same title?

We rewrote the Ghostty *G* *T* *K* application

The article about struggling... with GTK.

You didn't explain anything wrong with GTK. You just brought up Electron out of nowhere.

Electron is bringing an entire web browser in to provide a cross-platform user interface. GTK has become almost a web browser to provide a cross-platform user interface. That is why I started off with

> CSS classes

To spell it out, I think it is all excessive.

I don't think you know enough about GTK if you think having a CSS parser is bloat in a UI toolkit versus a whole theming engine.

Their CSS implementation is broader than what most actual browsers had 10 years ago. I would not have commented if I weren't already painfully familiar.

https://docs.gtk.org/gtk3/css-overview.html

It even has a DOM inspector window:

https://askubuntu.com/questions/597259/how-do-i-open-gtk-ins...

The negative aspects of Electron have little to nothing to do with CSS, and you're only invoking it here to poison the well by association.

You are projecting. Personally speaking, I would choose Electron waaaay before I'd choose GTK. That probably wasn't an option for his optimized terminal, but would be Good Enough™ for just about anything else.

I hate GTK enough that I'm considering porting Ghostty to literally any other GUI system. I think that Qt is probably the only alternative that anyone might consider "platform native" so I'll probably go that direction, even though Qt development is rather special in its own way (you know how GTK decided C needed an object system? Qt decided that C++ needed a more better object system).

> Qt decided that C++ needed a more better object system

I haven't used Qt, nor C++, in many moons, but my understanding was that `moc` [1] filled a gap of run-time dynamicism that C++ didn't natively support when it was invented. Has C++ since evolved to make that obsolete? Seems like moc is still a thing.

[1] https://doc.qt.io/qt-6/moc.html

I feel some genuine grief about what GTK has become.

It started out as a toolkit for application development and leaned heavily into the needs of the C developer who was writing an application with a GUI. It was really a breath of fresh air to us crusties who started out with Xaw and Motif. That's the GTK I want to remember.

What it is now is (IMO) mostly a product of the economics of free software development. There's not a lot of bread out there to build a great, free, developer experience for Linux apps. Paid GTK development is just in service of improving the desktop platform that the big vendors ship. This leads to more abstraction breaks between the toolkit, the desktop, and the theme, because nobody cares as long as all the core desktop apps work. "Third party" app developers, who used to be the only audience for GTK, are a distant second place. The third party DX is only good if you follow a cookie-cutter app template.

I switched my long-term personal projects from GTK2 to Dear ImGui, which IMO is the only UI toolkit going that actually prioritizes developer experience. Porting from GTK2 to GTK3 would have been almost as much work since I depended on Clutter (which was at one point a key element of the platform, but got dropped/deprecated -- maybe its corporate sponsor folded? not sure).

> GTK is by various definitions the most popular, widespread GUI toolkit on Linux that makes your app fit into _most_ ecosystems.

I disagree. Qt is also quite popular and much better at adapting to the environment it runs in.

How about wxWidgets or Tcl/Tk or Fyne?

This is where your fork can come in

This is really just my opinion but I always can’t tell when an app uses QT and not positively. QT just looks uglier and feels more windows XP-esque than GTK apps

I just use the default terminal, konsole, in kubuntu. Is Ghostty that much better?

No, Konsole is awesome.

Gtk is more than Gnome. It is also used by Xfce and other DEs. So while Qt is also popular, I think it's fair to call it the most popular.