5 ms·

API changes? They remove important user-facing features (like custom key themes[1]) without providing any real migration path. I wasted an afternoon trying to f

API changes? They remove important user-facing features (like custom key themes[1]) without providing any real migration path. I wasted an afternoon trying to figure out how can I make Gnome apps use super+c/super+v/etc like cmd+c/cmd+v on macOS and... no, as of Gtk4 you can't, not anymore. > 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 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). [2]: https://gitlab.gnome.org/GNOME/mutter/-/issues/217 https://gitlab.gnome.org/GNOME/mutter/-/issues/217

phkahler 4y ago
>> 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.
- zorr 4y ago
  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-state.html https://developer.gnome.org/documentation/tutorials/save-sta...
  - ohgodplsno 4y ago
    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.
    - zorr 4y ago
      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.
sprash 4y ago
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.
- TingPing 4y ago
  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).

phkahler 4y ago

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

zorr 4y ago
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-state.html https://developer.gnome.org/documentation/tutorials/save-sta...
- ohgodplsno 4y ago
  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.
  - zorr 4y ago
    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.

sprash 4y ago

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.

TingPing 4y ago
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).