Sadly bigger projects like GIMP or Inkscape didn't learn their lesson. Since version 3.0 GTK serves only GNOME and their particular demands for their severely limited desktop environment. The correct action would be to go back to GTK 2.0. It is far easier to continue to maintain GTK 2.0 than porting your app to a moving target like GTK3/4 with regular severe user and developer hostile regressions.

That is nonsense, the toolkit is like a million lines of code, constantly falling further behind. GTK2 doesn’t support a modern Linux machine well (Wayland, hidpi, GPU rendering).

>> Developers are users too.

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.

The window state is not the GTK devs problem but an app developer problem. One of the very first topics in the GNOME developer guide is how to use settings to save/restore window state on close/startup.

https://developer.gnome.org/documentation/tutorials/save-sta...

The window state is absolutely, partly GTK's problem, or at the very least _not_ the developer's problem. Storing window size yourself opens a whole can of worms, including but not limited to:

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

I explained in other siblings already why the toolkit cannot make assumptions about storing and restoring the window size. The app knows about the content and requests one or more windows with a requested size depending on its contents, and it's the OS/DE/WM that has to place it somewhere.

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

From that link:

"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 has some logic to it though: An application developer is going to use the toolkit to open one or more windows on startup and the DE/WM has to place those somewhere. The first window opened by the app is not guaranteed to be the main window and it's not guaranteed to always be the same window (sometimes it can immediately open the main app window but other times it might have to show a smaller login window first, or immediately open multiple windows, etc).

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

Not the GTK developers, the Gnome developers. Do it once, not once per app. There is no excuse for this.

As explained in a sibling comment, the toolkit cannot make assumptions about restoring an apps window state to its previous size. Sure it might work for simple hello world apps that always open the main window, but that's not always the case. Sometimes applications have to open a different window or multiple windows on app startup. The only thing the toolkit can reliably do is translate the requested window size when an application opens a window to the DE so that the DE/WM can place it on the screen.

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.

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

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