Hacker News Reader

Comment by chrismorgan | Hacker News Reader

I’m curious about this, because over the past decade or so, large parts of GTK’s cross-platform ability have been actively sabotaged. It used to be possible to style it to look native on Windows, with some feel problems but mostly comparatively minor. Now, well, no one has quite managed native look (whether or not it’s possible, and certainly I’ll allow that “native” is very ill-defined on Windows these days), and feel is way off in important ways because they’ve deliberately removed a number of important pieces, forcing GNOME HIG conventions. (Things like how they basically force GNOME’s style of overlay scrollbars these days; also keyboard stuff is regularly hopelessly wrong.) The GTK/libadwaita separation is a lie. The GNOME Foundation co-opted GTK and deliberately scupper it for everyone that’s not GNOME (whether on Linux or for other OSes).

So I’m curious whether this sort of patch would be accepted. Assuming reasonable quality of patch, it pretty obviously should be if you want to be a cross-platform toolkit that doesn’t feel massively out of place, but without knowing what position or connections Paul Rouget may have, I’m honestly sceptical that such a patch would be accepted.

View on HN

This comment is not correct. GNOME Foundation didn't co-opt or sabotage GTK. For a very long time it's just been mostly GNOME people contributing. It's a known problem that GTK needs more people contributing to fix issues on other platforms. No one I've talked to at the Foundation is happy about this either. If you're bothered about this, you should consider showing up and start contributing.

GTK4 and Adwaita apps can still be styled however the developer wants. If some app developer wants to make a Windows theme, go for it.

Overlay scrollbars aren't forced. The app developer can disable that and make the scrollbars always show. You might not want to though, because some Windows apps do have overlay scrollbars. For example: VS Code.

Keyboard shortcuts are also up to the app developer. If someone wants to have some compile time setting to change the keybinds when building on Windows, go for it.

I have no idea what you're saying about libadwaita separation. You can very clearly look at the libadwaita code and see what's in there versus what gets upstreamed into GTK. No one has any way to lie here. It's just an extra set of GTK widgets you can optionally use.

The draft MR written by Paul is still open. I doubt it will be merged in the current state it's in, because it has bugs.

You’re viewing things from the wrong angle.

To begin with, the onus of all of these things has been shifted to the app developer. Previously, a lot of it was up to the user or the desktop environment.

I said “basically force” because non-overlay scrollbars are possible, but getting them requires every app’s developer to change the property everywhere. If (I recall correctly, it’s not even a theme thing.) That’s completely unrealistic, quite apart from there being no convention. Firefox gets an “always show scrollbars” checkbox in its preferences, which you can manually tick; but I haven’t come across anything else exposing it.

Keyboard: I wasn’t speaking of keyboard shortcuts, actually but other details like what arrow keys do, how text is selected by keyboard (e.g. Ctrl+Shift+Left/Right: which punctuation marks word boundaries, what punctuation or whitespace do you include in the direction of selection). Windows has strong conventions on how those sorts of things work, and my recollection is that GTK does things the GNOME way rather than the Windows way when on Windows.

libadwaita: they said “we’ve split out GNOME HIG stuff into libadwaita, GTK is now more platform-neutral”. In practice, compared to GTK+ 2, even more GNOME HIG is baked into GTK, even more strongly: in the past, users and desktop environments could override various of the stuff; now, the app developer has to support it, or you have to maintain increasingly onerous patches against their source code. That’s the problem. As for what’s in libadwaita, it’s mostly just a few widgets, and various functionality such as colouring stuff that seems to me to pretty clearly belong in libgtk (because it’s useful almost everywhere, and other platforms have analogues which you want to be supported out of the box).

I’ve written more about the bad direction GTK has headed in: https://hn.algolia.com/?query=chrismorgan+gtk&type=comment

>You’re viewing things from the wrong angle.

Nope, the onus is always on the app developer. Even Microsoft is inconsistent with their own Windows apps using overlay scrollbars. Old Windows apps don't have them, but the new app guidelines for Windows 11 actually say you should use overlay scrolling: https://learn.microsoft.com/en-us/windows/apps/design/contro...

Windows developers just have to pick which guidelines they want to follow, that's how it goes. I don't know the specifics of keyboard interactions but I'd imagine it also changes over time in Windows and varies depending on the app, because that's how everything is in a nearly 40 year old operating system.

I'll steelman your argument anyway: say there was a standard behavior for all of these things. Someone could start doing a lot of testing on Windows and conceivably adding lots of #ifdef _WIN32 to GTK. That isn't particularly hard to do. The problem is then how that affects the apps if the toolkit now has some behaviour that only manifests on Windows. App developers then have to test that and ensure it doesn't break their apps in that specific environment, and if any behaviour is undesired then they have to start adding more #ifdef _WIN32 as well to the apps. Like if an app has a custom text widget or a custom scrollbar, what will they do? You also can't fix that by making them a runtime switch instead of an ifdef. If there was any custom stuff at all, the users and desktops still couldn't override it unless the app developer added another switch.

There just isn't any way around it, the app developer has to handle it. This is a problem with any toolkit that runs on multiple platforms. I can see why you would think it was less of a problem in GTK 2, because less apps were using it so they had less opportunities to make fancy widgets that don't fit in on Windows. Old GTK 2 versions of Inkscape had their own weird bugs, they were just different bugs. None of these can really be fixed in a toolkit, even Qt has problems which you seemed to acknowledge in another comment:

>Of course, other options in a similar space like Qt aren’t entirely better

I've looked through a few of your other comments too and my answer is the same: If you think the direction is bad, then you should show up and start fixing all the open GTK bugs on Windows. Don't just report the bugs, actually fix them. There aren't enough people to even do that, never mind start adding a bunch of extra Windows functionality. And if you do catch up to the point where you can add extra functionality, then you have to stick around for long enough to fix all the new bugs. That's the deal with volunteer projects like GTK: there is no money to hire experts, if you're an expert in Windows development who wants things done then you need to step up and volunteer.

Certainly some user preferences could damage some apps. But it mostly didn’t, it was generally good enough, and when it did it commonly pointed to a bug in the app anyway (e.g. setting text foreground colour when you don’t know what the background colour is—you must always set (or know the value of) either neither or both). And this flexibility was used by a variety of platforms.

Since you mention overlay scrollbars again, I’ll emphasise something I only alluded vaguely to in my initial wording: GTK does GNOME-style overlay scrollbars. The look and feel are both completely different from Windows 10 and 11 overlay scrollbars, and you certainly can’t accurately emulate the behaviour and I doubt you can emulate the look either. I’ll also mention something that apparently didn’t make it into my previous comment: macOS lets you turn overlay scrollbars on or off at the user level.

As for getting involved: they’ve been actively and deliberately gutting stuff useful for other platforms, and refusing to undelete things because of their vision of how things should be, seen most clearly in how they’ve handled overlay scrollbars and theming. I’m not interested in getting involved with a project like that; it seems to me fairly clearly a lost cause for anything I could do, if I was even willing to spend that kind of time on such a thing.

>But it mostly didn’t, it was generally good enough, and when it did it commonly pointed to a bug in the app anyway

That hasn't changed though? The individual settings might have changed. Some were added and some were taken away, as is usual in development.

>The look and feel are both completely different from Windows 10 and 11 overlay scrollbars, and you certainly can’t accurately emulate the behaviour and I doubt you can emulate the look either.

If there are subtle things then no you probably can't without writing a new widget. So again, you're talking about having a big #ifdef inside the scrollbar code. Practically speaking the maintainers would then have to maintain at least two separate scrollbar implementations. Those are the Windows 11 scrollbars though, what about the old Win32 scrollbars that are still used in a lot of places? Do you skin them to look and act like Windows 11? 10? 8? Vista? Do you change that at runtime by detecting the OS version? Just looking at the scrollbars on my Win 11 install I see at least 4 different scrollbar styles. So which ones do you support?

Say you decide to go the easy route and only support the default Windows 11 scrollbars with the overlay. Fine. They won't look right if you run them on Windows 10 or 8 but whatever. So when when Microsoft releases a new version or changes the behaviour of the scrollbars, you still have to track that and release a new version in step with Microsoft so it doesn't get out of date. If you want everything to be consistent then you have to do it with every widget, not just scrollbars. That's easily several full time jobs just doing that, which no one has been available to do. Because realistically you need people who are expert Windows developers as well as expert GTK developers, and they have to be willing to volunteer to work for free full time because GTK is a volunteer project. As far as I've seen those people just don't exist.

Really though, I don't think it's as big a problem as you're making it out to be since Windows apps are already widely inconsistent with regard to every widget, including scrollbars.

>macOS lets you turn overlay scrollbars on or off at the user level.

Compared to the work of reimplementing everything, it's not particularly hard to push another boolean setting through the code. It's already there on the app level. But like you say, that wouldn't really solve anything.

>they’ve been actively and deliberately gutting stuff useful for other platforms, and refusing to undelete things because of their vision of how things should be

Every project has a vision of how things should be. That's what separates every project from the rest. That isn't why this is happening though; most of the time they're refusing to undelete things because no one is around to maintain them. You don't just bring code back into the project and suddenly it works, someone has to do actual work to make that happen. If you can make a real good case for bringing back that code, and you can show you'll do the work and you won't disappear, then that person could be you. Currently I don't think any maintainers are Windows developers, they're just trying to keep roughly the same amount of Windows functionality working within the time they have available to work on it. Which is not a lot of time.

But I can see you've already made up your mind that the developers are trying to make things worse for you and sabotage you because they don't like you or something, so I doubt I can convince you of anything. This is why I don't enjoy engaging with this forum often. Have a good one.

Unfortunately I agree with your analysis, I feel like GNOME is sabotaging not only the other platforms, but its own native one as well[1], to the detriment of the broader FOSS ecosystem. On the other end you have extreme minimalism like dwm, and the middle-ground like lxqt always felt lacking in polish.

What's the state of wxWidgets nowadays? I feel like they've always had the most honest approach to cross-platform support.

[1]: https://news.ycombinator.com/item?id=35650663#35653129

Nothing was sabotaged there. Custom key themes were removed because the whole concept of them was broken. The only one anyone ever seemed to use was the Emacs theme and that just broke apps because they didn't handle the case when an Emacs binding conflicted with the app's own keys. It would get even worse if you had your own custom key theme, there's nothing reasonable an app can do when you add a bunch of key binds that break its keys.

On Linux, WxWidgets is just a wrapper around GTK or Qt, so it would still inherit all the problems of those toolkits.

> Custom key themes were removed because the whole concept of them was broken.

The concept was never broken on macOS. It's also implemented in a brilliantly simple and very user-accessible way, and requires very little consideration from the application developer. Between that, or having a single configuration file where one can achieve a similar result, deciding which method is better probably boils down to personal preference.

No more personal preference for me though.

> The only one anyone ever seemed to use was the Emacs theme and that just broke apps because they didn't handle the case when an Emacs binding conflicted with the app's own keys.

Again, macOS does effectively have what can be summarised as "Emacs keybindings": C-a, C-k, C-b, etc all do what you expect them to do, and if you do ever find any particular key combo conflicting for some obscure reason, you have a simple, system-level tool to fix it.

I know the issue under GNOME mostly comes from trying to find a compromise between copying what Windows does, and what's native to the terminal, but all I'm really trying to achieve is to have a consistent working environment.

The way things are: in the terminal, Ctrl-C sends an interrupt, and Ctrl-Shift-C (or some other combination, depending on your terminal emulator) copies text; in Emacs C-c is a command prefix, and M-w is copy; etcetera. I find working like this frustrating; I could probably stomach having Ctrl-C as copy everywhere (even if it meant doing something unspeakable to the terminal emulator to keep the ability to send SIGINT to the foreground process), but I used to be able to whackamole every app into respecting my preference for using Cmd-C for that. Switching between all these conventions is unnecessary mental fatigue.

I know my argument is pretty much <https://xkcd.com/1172/>, but it's still quite disappointing that the "free" desktop is where my preference is disrespected.

>The concept was never broken on macOS

Yes it is, MacOS also doesn't have key themes. I can't reconfigure a Mac to use Windows keyboard shortcuts. Those are just the default key bindings every Mac app has to support. That's why it works on Mac and it doesn't work on Windows or Linux or anywhere else where the defaults are different. You're comparing apples to oranges here.

To elaborate, Mac gets away with it because historically it has Command as an extra modifier and uses that as the primary modifier key. The Control key isn't used for anything else on Mac. GTK apps need to support non-Mac keyboards where Control is the primary modifier key. The Win or Super key on PC keyboards is historically not used often as a modifier. If it is used as a modifier it's often only used by the shell, not by an app. So, what is consistent for you depends on platform conventions anyway.

>but it's still quite disappointing that the "free" desktop is where my preference is disrespected.

This isn't a desktop preference, you're asking every app to fundamentally change the way its keybindings work. The "free" in free desktop means that if you want to change all keybindings for every app to work to your preference, then you get to fork those apps, change the code yourself, recompile and then deal with any of the resulting bugs. It doesn't mean that suddenly every preference that you want will start working without any extra effort or causing additional bugs.

> I can't reconfigure a Mac to use Windows keyboard shortcuts.

Yes you absolutely can. I've tried it and you can rebind copy/paste/undo/etc globally to use Ctrl-c/Ctrl-v/Ctrl-z/etc, using the builtin Settings.app. It takes about a minute or two, a bit more if you want to change everything as you have to rebind them one by one by hunting down the command names in the menus. You can rebind anything for all apps, or only for a specific app. You can also swap Cmd and Opt. This is probably easier for newbies than editing a text file, but you can't trivially check it into git. I still have a PowerPC Mac with OSX 10.5, I should probably check if it was supported at the time, but my hunch is that it was. The point is it's there, out of the box, and it's working extremely well.

The most interesting thing with this setup is what the terminal does: Ctrl-c copies the text when something is selected, and sends SIGINT otherwise. You're having and eating your cake on so many levels.

> The Win or Super key on PC keyboards is historically not used often as a modifier.

Yes and no. The scan code is the same as Cmd. If you plug an Apple keyboard to a PC or a PC keyboard to a Mac, the only issue is figuring out if you want to swap it with Alt/Opt.

Cmd/Win has also always been a very popular choice for the "modifier" key in minimalistic/tiling window managers, and GNOME has supported that too, even back in the early 2.x days (I'm not old enough to remember 1.x). Even Windows started using Win-E for things like launching the file manager, Win-P for configuring the screens, Win-arrow keys for window placement, etc - some of that more than 20 years ago IIRC. So it's not like there's no historical precedent, it's always been about conventions, platform defaults, and what do you want to leave up to the user.

I fully agree with "convention over configuration", but if you take away the "configuration" part, what's left is "my way or the highway".

> The "free" in free desktop means that if you want to change all keybindings for every app to work to your preference, then you get to fork those apps, change the code yourself, recompile and then deal with any of the resulting bugs.

Well, I could argue up until this point, but this is the suckless.org attitude. Awesome. Is this how dwm becomes more user-friendly than GNOME?

FYI I've never had to compile Emacs, Sway, or Alacritty (or ANYTHING on Mac) just to change the key bindings, and I'm definitely the guy who tries to change EVERYTHING.

>Yes you absolutely can. I've tried it and you can rebind copy/paste/undo/etc globally to use Ctrl-c/Ctrl-v/Ctrl-z/etc, using the builtin Settings.app. It takes about a minute or two, a bit more if you want to change everything as you have to rebind them one by one by hunting down the command names in the menus

Sorry I don't count that, this is comparing apples to oranges again. It's still not the same as key themes. You're doing the same thing I was talking about earlier, manually reconfiguring every shortcut in every app and dealing with all the resulting bugs yourself. It doesn't work either if the command has a slightly different name for some reason. Even if you wanted this type of configuration in GNOME, and if it were even possible, which it sort of is already, it still would be implemented in a completely different way than key themes were. Because key themes were just broken.

The difference is key themes are another thing that claims to do it automatically. If they were working correctly there would be no conflicts. They don't though, so either way if there are conflicts you have to hunt those down and reconfigure every app individually again and then you get to remember which apps have different shortcuts because you had to do something weird to resolve the key conflicts. The point is, I can't just flip a switch that changes everything to Windows shortcuts.

The other issue here is how this relates to GTK and GNOME apps. Technically, GTK still has an API to create Mac-style menu bars. GNOME apps don't use that API as a matter of convention because GNOME doesn't have a global menu bar like Mac does. If they did, it would be a lot easier to build that same kind of setting GUI. But they don't. So, as always, it still comes back to how the app developer chooses to make the app and what platform conventions they follow. Please be aware of what you're asking for here, it may seem like a simple request to you but when you dig into it it's really asking to change several things in every app to be more like some other platform. And that's not a reasonable request unless you're willing to see it through all the way.

>Ctrl-c copies the text when something is selected, and sends SIGINT otherwise. You're having and eating your cake on so many levels.

This behaviour is again dependent on how the terminal handles the menu. It could be implemented in a different way where it always interprets it as Copy even when nothing is selected. It won't work at all if you have another key theme where Ctrl-C is an action that's always enabled. And what if I want to rebind SIGINT in this scenario, how does that work? I don't expect terminals to add a menu entry for every terminal escape, but that's how they would have to do it using the Apple approach. Or they have to add their own setting for this, which is no better than before.

>Well, I could argue up until this point, but this is the suckless.org attitude.

No, this is the everything attitude. An app developer can always choose what settings they want to present to the user and what features they want to support. If you don't like it, then yes, most of the time it's "my way or the highway". That's how this software thing works, open source or closed source. Mac, Windows, Linux, all of them have a different collection of settings they support. If it's open source you just always have the extra option to recompile if the original developer didn't want to do it.

> [...] You're doing the same thing I was talking about earlier, manually reconfiguring every shortcut in every app and dealing with all the resulting bugs yourself. [...] Because key themes were just broken.

OK so what is the ideal solution in your opinion? If key themes are broken, and having the ability to reconfigure a single key (for any single, or all apps) in a central place is also broken, then what isn't? Hardcoding all key combos in the source? Having every app developer build a custom settings dialog where maybe they will, or maybe they won't let you configure a given shortcut?

> Technically, GTK still has an API to create Mac-style menu bars. GNOME apps don't use that API as a matter of convention because GNOME doesn't have a global menu bar like Mac does. If they did, it would be a lot easier to build that same kind of setting GUI. But they don't.

You don't need to draw a menu bar on the screen in order to keep track of the actions that the app exposes to the user.

> It could be implemented in a different way where it always interprets it as Copy even when nothing is selected.

But it wasn't, and that's my entire point. It's your choice to do something that supports and empowers the user, or to throw a wrench in the cogwheels.

> If it's open source you just always have the extra option to recompile if the original developer didn't want to do it.

And if the developer chooses to ignore the needs of their user, the user is free to go somewhere else.

>OK so what is the ideal solution in your opinion?

Cheeky answer: The ideal solution is a smartphone. It has no keyboard. You don't have to worry about keybindings at all anymore.

Real answer: There isn't one. Once apps can do their own keyboard handling and make their own keybindings, any hope of making a clean solution goes out the window. It's hacks upon hacks from there on, because anything a new app does could potentially conflict with your settings. The Mac solution isn't perfect either but is definitely more flexible and less broken than key themes.

>You don't need to draw a menu bar on the screen in order to keep track of the actions that the app exposes to the user.

Yes, you're correct. GNOME apps could use the app menu API anyway, the menu wouldn't be visible, but some settings GUI could look at the information exposed by the API and use that to do other things. In practice they don't use that API at all because it has no visible effect for GNOME users, and it's not very compelling to require them to use an API that only adds some actions that are hidden away in a settings panel somewhere. Sure you could change this. But you have to convince every app developer it's a good idea to start doing it when they've already taken a lot of steps to move away from menu bars. Including completely removing them from the HIG. I'm not trying to say this is impossible but it's a major change that will affect every app, and you would have needed to do something similar anyway if you were trying to fix key themes to not be so broken.

>But it wasn't, and that's my entire point. It's your choice to do something that supports and empowers the user, or to throw a wrench in the cogwheels.

No, I've seen plenty of apps where Copy with nothing selected takes some reasonable action. Like if you pressed it after opening a dialog displaying a short document, it could copy the entire document for convenience. I can't say no one will ever come up with some reason to do this in a terminal. If it's a Mac terminal, they have few incentives not to because there isn't a key conflict by default with Ctrl-C. If you go around changing your keybindings and you break that, it's on you. Then you probably want to change it back after you find out it's broken. No one can predict what an app will do, that's the point of letting them handle their own keybindings.

>And if the developer chooses to ignore the needs of their user, the user is free to go somewhere else.

By all means, if you like the way Mac handles this, you should use a Mac. Different operating systems are different for a reason.

> By all means, if you like the way Mac handles this, you should use a Mac.

So let me recap:

1. You've said Gtk/GNOME relies on volunteer contributions;

2. GNOME removes (or refuses to implement, mutter#217) perfectly reasonable features that both regular and power users need/want/rely on, without providing alternatives (unless the plan is to get libadwaita eventually linked into the kernel);

3. You tell someone who shows interest in said features (outlining alternative designs, implementations, diving into some of the edge cases, and weighting their pros and cons), that if they like these features, they should use macOS instead.

Conclusion: GNOME drives away the same people who have the motivation and expertise to contribute to the platform. Self-sabotage.

Here's a hint: it works for Apple, because Apple produces a polished and highly desirable product. But even Apple caters to their professional audience. It works for suckless, because they're elitists and mostly irrelevant. But even suckless maintains an official repo of community patches.

How many active forks of KDE do we have out there?

I’m now curious whether Emacs key bindings work in GTK text boxes on macOS.

It's inconsistent. I haven't touched my Gtk settings on macOS, and here are the defaults: Ctrl-A in Gimp (Gtk2) selects all text; in Inkscape (Gtk3) it hops to the start of the line; I'm not sure which apps use Gtk4 so can't tell for this one.

Reply on news.ycombinator.com