GUI development with Rust and GTK 4

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.

Absolutely. XML is rarely a good solution for any problem, and usually the worst.

> I’d like to do the same for Android projects, but Google is hellbent on the XML usage if you’re building with Android Framework…

For sure the Android API is oriented towards building GUIs in XML, but it's actually quite possible to build your Android GUI in Java code.

When I started developing for Android, I took a look at a few tutorials and said "no way", searched the web for how to build Android GUIs programmatically, and never looked back.

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.

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

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