I hope this makes the GTK developers realize how detrimental API change can be. I get that some things need to change, but how many other open source projects are going to have some level of trouble keeping up?
> I'm personally not sure that "user must have an ability to redefine every keyboard shortcut" [...].
[1]: https://gitlab.gnome.org/GNOME/gtk/-/issues/1669
Developers are users too. They are also arguably your most important users - they turn products into ecosystems, their involvement is a force multiplier for your platform. As Gnome is actively hostile towards their users, I'm not surprised they don't care much for third-party developers either (both inside and outside[2] of their ecosystem).
For a GUI toolkit, developers are the only users in one sense.
>> > I'm personally not sure that "user must have an ability to redefine every keyboard shortcut"
I'm not either, but I agree it sucks to just remove existing functionality. OTOH reading the thread it seems on MacOS you can define that outside the application, so integrating with that would be a requirement - did they do that before?
We get people wanting to redefine shortcuts sometimes and I'm just like "wow, can't people just accept the defaults? I'm not even sure how to go about implementing that, never mind on 3 platforms..."
My current UI complaint is corruption of the title bar. Gnome has allowed widgets up there now. Even if I accept the desire to use the space, some widgets can be used to drag the window while others can not. The primary purpose of clicking up there is to move a window and I can't tell if/where I can do that any more. BTW moving windows is important now with Wayland because Apps can't remember where they were and put themselves there on opening, and the Gnome guys haven't realized that's their job now. BTW I agree with the Wayland thinking on this, it's just that the DE hasn't caught up yet.
Also on Windows, MS has made some title bars white/grey and some blue. Same with toolbars. So now when I have multiple windows overlapping it's impossible to tell what is attached to what and what will move the window I want to move. It's like GUI designers think "oh I'd like this" but don't even consider the collateral damage the change will cause.
https://developer.gnome.org/documentation/tutorials/save-sta...
- Yay, one more half baked implementation of loading a file and reading it, with a bit of bad luck it'll be in C too. Surely this will not lead to problems!
- Yay, your app now probably has to bother with saving DPI info and restoring that properly when using a different screen with different DPI.
- Yay, your app now has to bother with not positioning the window out of bounds in case it was on another screen. Surely this will not lead to problems!
You have now added dependencies on displays, IO, parsing. To restore the window's position. Add in client side decorations in this mess to make it even better.
It is an OS/DE's responsibility to give me windows. I'll put whatever the hell I want in there, and it's my job to save that content, but pretending that saving window state is the job of the app is some peak clown shit. On a scale of how bad of a UI toolkit this puts you, you are now at "Win32". Congrats Gtk4.
> - Yay, one more half baked implementation of loading a file and reading it, with a bit of bad luck it'll be in C too. Surely this will not lead to problems!
The link I provided documents this exact process in 4 languages including C and JavaScript and all the saving/loading/parsing and even binding the managed settings to the properties of a window is handled for you by the toolkit. It is 1 function call to initialize the settings and 1 function call per setting to bind it to the window property you want to manage. Oh, and these settings can be configured externally with various tools or GUI's as well if you want to.
> - Yay, your app now probably has to bother with saving DPI info and restoring that properly when using a different screen with different DPI.
AFAIK this is not something the app developer has to do and is handled by the DE with maybe a little help from the toolkit.
> - Yay, your app now has to bother with not positioning the window out of bounds in case it was on another screen. Surely this will not lead to problems!
Nope, an app can only request windows with some requested size, and it's up to the DE/WM to place it. Take tiling window managers for example which might be configured to always open new application bottom right, or top left, or floating or whatever. Sure, an app might dig down into the lower levels to finetune behavior but then the app developer chooses to open this can of worms to make sure it still works with all flavors of DE's/WM's/X11/wayland/etc
> You have now added dependencies on displays, IO, parsing. To restore the window's position. Add in client side decorations in this mess to make it even better.
GTK already has these dependencies and abstracts them for you in higher level API's while still providing access to lower level API's if you choose to use them. (Gdk for displays, Gio for IO and parsing/saving/loading and binding to settings is in Gio as well). Client side decorations is a matter of choosing what base window type you use, so you can have default decorations or start with a blank slate.
I honestly don't know what you expect GTK to do more than it already does.
Because of the dynamic nature of opening windows, app developers should have control over storing/restoring the window size. Simple apps might always store the last window size and restore that exact size on startup. Other apps might have to run some logic first before they know how large the window should be, and then request the toolkit to create a window of that size.
"The position of the window is best left to the window manager."
Why TF they think size is the apps problem but location is the WM problem is beyond me.
- It is the responsibility of the application developer to determine for each window what size it should be depending on the content in the window which can be dynamic. It's also not a fixed thing, but more a hint to the DE. The relevant GTK method is called gtk_widget_set_size_request(width, height) with the focus on "request" (defined in widget but window inherits it). Saving/restoring window state is left to the developer because of the dynamic nature of windows as explained above.
- It is the responsibility of the toolkit to make sure the window gets created and then communicate the requested size to the DE so it can be placed on the screen.
- It is the responsibility of the DE/WM to place this window where the user expects it and depending on the type of DE/WM it might have different behavior. For example a tiling window manager might be configured to always open new windows in the bottom right, or top left, or have config overrides for specific applications to always open floating or maximized.
So yes, the size is the apps problem (because it knows what content is on a specific window and might know about the previous window size from last time), and the position is the DE's responsibility because that can depend on user configuration and the specific DE/WM used. The app cannot make any assumptions about that. It can only request windows with a specific size.
The way this works on macOS is every application defines the top bar menu actions (which can be referenced by their name, e.g. "New Tab", "Copy", etc), and any of these actions can then be referenced by specific keyboard shortcuts - either system default, as defined by the app, or as re-defined (app-specific, or system-wide) by the user. Any redefining can be done in the System Preferences (now Settings) app, so as long as your app uses the system menu, your users get arbitrary user-defined shortcuts for free, with zero extra effort on your side.
This applies to every keyboard shortcut - you can redefine Cmd-C to Ctrl-C if that's what you like. I just checked it and it works. It even does the most sensible thing in Terminal (copies text if something is selected, and sends interrupt otherwise).
I've also checked this right now in Gimp (Gtk2) and Inkscape (Gtk3), and both apps support this functionality on macOS, so I think what the developer referred to here was specifically user-defined shortcuts in Gtk CSS - which leaves Gtk4 on the open source desktop as THE platform that now doesn't support it in any way anymore.
I'm pretty disappointed as before switching to a Mac, I spent almost 15 years on Linux/BSD, and got used to being able to customise anything - with enough hackery, nothing was out of reach. All I actually want is not customisation, but consistent keyboard shortcuts between Linux and Mac. It's pretty disheartening that it's easier to make Mac shortcuts work like on Linux than vice versa.
> We get people wanting to redefine shortcuts sometimes and I'm just like "wow, can't people just accept the defaults? I'm not even sure how to go about implementing that, never mind on 3 platforms..."
On macOS, you have to actually go out of your way to NOT support that. I don't think I've ever seen anything like Mac's shortcut system on Windows or Linux, but this is why things like gtk-key-theme and key bind properties in Gtk CSS have always existed.
And this is precisely the value of a cross-platform toolkit, it is supposed to help you (the application developer) not think too hard about these platform specific details, and provide the user with an escape hatch when they have a case you didn't think about (I'm a big fan of stylish/custom CSS for this reason).
> Also on Windows [...]
I think the situation on Windows has already been steadily turning dire by the time of XP, and hit an inflection point with Vista. I don't even mind a new look sometimes, but for goodness sake, clean up your mess MS...
As developer of another open source project that uses GTK2, I'd note that one of the beautiful things about open source is that for the most part, we do not have to keep up. Worst comes to worst, we dump GTK2 into our source tree ("vendoring") and keep using it.
There are hundreds to hundreds-of-thousands of applications that do not have a native Wayland version? Are you suggesting that you would not run any of them either?