4 ms·

It's still ironic to me that the program that GTK was made for and that popularized the toolkit, haven't managed to move to its latest version yet.

superkuh 3y ago
Gtk3 and Gtk4 have been ...well, gimped, and don't have many features. They've been removed in Gtk3/4 by GNOME developers because their DE does not prioritize things like keyboard entry (as compared to mouse use, see gtkfilechooserwidget.c in gtk3/4 not supporting keyboard based pasting of file paths without errors, https://gitlab.gnome.org/GNOME/gtk/-/issues/5872 https://gitlab.gnome.org/GNOME/gtk/-/issues/5872). Gtk2 hasn't fallen victim to this slow erosion of functionality.
- pengaru 3y ago
  I doubt breakages like the one you linked are deliberate, there's just a severe lack of manpower. My firsthand knowledge of such things is quite stale nowadays, but I get the impression the RH desktop group is barely on life support at this point. That GTK4 happened at all strikes me as surprising, but could be interesting long-term in terms of modernized GPU support for the toolkit attracting new usage/developers. The real question is do enough people even care about GTK anymore to make use of it in the future. I'm inclined to believe the current crop of devs want $hipster-language-native GUI packages. Not awkward quasi-"idiomatic" bindings and FFI wrapping an archaic C library like GTK/glib.
  - superkuh 3y ago
    Right. The example I gave, gtkfilechooserwidget.c, is such a mess of spaghetti code that the remaining Gtk developers don't want to touch it. Despite me bringing it up with them once per year and even providing a partial patch to work off of. But of course that didn't stop them from messing with it in 2014 and breaking it and leaving it in a broken state. The developer that broke it, mclassen, is still there and still explicitly says not having keyboard filepath paste is not a bug. Despite it giving an error message. re: Gtk4, they're already moving on to Gkt5 (wayland only though https://www.phoronix.com/news/GTK5-Might-Drop-X11 https://www.phoronix.com/news/GTK5-Might-Drop-X11).
    - pengaru 3y ago
      There's no mention of the issue being keyboard-specific nor patches or comments from mclassen in the issue you linked. Maybe you linked the wrong one? Looks like a canonical file path (as opposed to dir path) paste handling bug in general, which seems like something worth fixing regardless of one's stance on keyboard paste.
      - superkuh 3y ago
        I talked to them myself on #gtk on IRC (both on gimpnet in the old days and libera in modern times). Most previous issues with this bug have been removed from the bug tracker(s). This is just the latest one submitted by a helpful dev in channel who discovered it applied to Gtk4 too when I brought up the Gtk3 version this year. Now that they know it's in Gtk4 too they might do something. To understand how it's keyboard specific you have to know about what features were removed. In the past you could set the file chooser dialog to have either a text entry field or the path-bar mouse buttons as the default. This was through org.gtk.Settings.FileChooser location-mode. While this gsetting still remains gtkfilechooserwidget.c was changed so it no longer respects those settings and always forces only the mouse based path-bar input mode. This means now when a file path is pasted with ctrl-v (or middle mouse click paste?) the entirely wrong function tries to handle it and this function errors out because it's not expecting file path input.
  - gnulinux 3y ago
    "Lack of manpower" is not a valid excuse when it comes to Gnome/GTK. If you redesign your entire codebase every other year, break everyone's workflow you cannot cry about lack of manpower. Writing software is one of the most expensive human endeavors in the world right now and FOSS community treats it like they have unlimited supply of it. If you have limited supply of software engineers then you cannot afford to redesign your UI and you have to stick to your existing code.
bitwize 3y ago
While GTK started off as the GIMP Toolkit, it has since become the GNOME Toolkit, so it doesn't really track GIMP's needs anymore.
formerly_proven 3y ago
They can port GIMP to the QML-based UI framework used by Muse 4.
- PaulDavisThe1st 3y ago
  I would estimate that would be a 3 person-year project, and the result will contain precisely zero improvements for any user (even if theoretically it might be easier to bring various improvements after that is done). That is a hell of an ask.
  - formerly_proven 3y ago
    Would be funny though And would it be more work than the gtk2->gtk3 port?
    - PaulDavisThe1st 3y ago
      Substantially more work. However, what people do not realize about these "toolkit ports", whether within a family (GTK 3->4) or across them (Qt -> GTK), is that the reason they take so long is that it is almost impossible, when having to go through the vast majority of the codebase and change stuff everywhere, to avoid the realization and/or temptation that there are better (or at least different) ways to do things. If you could suppress that inclination (and its not clear that doing so is a good idea), and simply do as close to a 1:1 replacement where required (which for cross-family ports is everywhere), the port could be a lot faster. But it is extremely hard to resist that, because the non 1:1 replacement stuff just appears so right.

superkuh 3y ago

Gtk3 and Gtk4 have been ...well, gimped, and don't have many features. They've been removed in Gtk3/4 by GNOME developers because their DE does not prioritize things like keyboard entry (as compared to mouse use, see gtkfilechooserwidget.c in gtk3/4 not supporting keyboard based pasting of file paths without errors, https://gitlab.gnome.org/GNOME/gtk/-/issues/5872 https://gitlab.gnome.org/GNOME/gtk/-/issues/5872). Gtk2 hasn't fallen victim to this slow erosion of functionality.

pengaru 3y ago
I doubt breakages like the one you linked are deliberate, there's just a severe lack of manpower. My firsthand knowledge of such things is quite stale nowadays, but I get the impression the RH desktop group is barely on life support at this point. That GTK4 happened at all strikes me as surprising, but could be interesting long-term in terms of modernized GPU support for the toolkit attracting new usage/developers. The real question is do enough people even care about GTK anymore to make use of it in the future. I'm inclined to believe the current crop of devs want $hipster-language-native GUI packages. Not awkward quasi-"idiomatic" bindings and FFI wrapping an archaic C library like GTK/glib.
- superkuh 3y ago
  Right. The example I gave, gtkfilechooserwidget.c, is such a mess of spaghetti code that the remaining Gtk developers don't want to touch it. Despite me bringing it up with them once per year and even providing a partial patch to work off of. But of course that didn't stop them from messing with it in 2014 and breaking it and leaving it in a broken state. The developer that broke it, mclassen, is still there and still explicitly says not having keyboard filepath paste is not a bug. Despite it giving an error message. re: Gtk4, they're already moving on to Gkt5 (wayland only though https://www.phoronix.com/news/GTK5-Might-Drop-X11 https://www.phoronix.com/news/GTK5-Might-Drop-X11).
  - pengaru 3y ago
    There's no mention of the issue being keyboard-specific nor patches or comments from mclassen in the issue you linked. Maybe you linked the wrong one? Looks like a canonical file path (as opposed to dir path) paste handling bug in general, which seems like something worth fixing regardless of one's stance on keyboard paste.
    - superkuh 3y ago
      I talked to them myself on #gtk on IRC (both on gimpnet in the old days and libera in modern times). Most previous issues with this bug have been removed from the bug tracker(s). This is just the latest one submitted by a helpful dev in channel who discovered it applied to Gtk4 too when I brought up the Gtk3 version this year. Now that they know it's in Gtk4 too they might do something. To understand how it's keyboard specific you have to know about what features were removed. In the past you could set the file chooser dialog to have either a text entry field or the path-bar mouse buttons as the default. This was through org.gtk.Settings.FileChooser location-mode. While this gsetting still remains gtkfilechooserwidget.c was changed so it no longer respects those settings and always forces only the mouse based path-bar input mode. This means now when a file path is pasted with ctrl-v (or middle mouse click paste?) the entirely wrong function tries to handle it and this function errors out because it's not expecting file path input.
- gnulinux 3y ago
  "Lack of manpower" is not a valid excuse when it comes to Gnome/GTK. If you redesign your entire codebase every other year, break everyone's workflow you cannot cry about lack of manpower. Writing software is one of the most expensive human endeavors in the world right now and FOSS community treats it like they have unlimited supply of it. If you have limited supply of software engineers then you cannot afford to redesign your UI and you have to stick to your existing code.

bitwize 3y ago

While GTK started off as the GIMP Toolkit, it has since become the GNOME Toolkit, so it doesn't really track GIMP's needs anymore.

formerly_proven 3y ago

They can port GIMP to the QML-based UI framework used by Muse 4.

PaulDavisThe1st 3y ago
I would estimate that would be a 3 person-year project, and the result will contain precisely zero improvements for any user (even if theoretically it might be easier to bring various improvements after that is done). That is a hell of an ask.
- formerly_proven 3y ago
  Would be funny though And would it be more work than the gtk2->gtk3 port?
  - PaulDavisThe1st 3y ago
    Substantially more work. However, what people do not realize about these "toolkit ports", whether within a family (GTK 3->4) or across them (Qt -> GTK), is that the reason they take so long is that it is almost impossible, when having to go through the vast majority of the codebase and change stuff everywhere, to avoid the realization and/or temptation that there are better (or at least different) ways to do things. If you could suppress that inclination (and its not clear that doing so is a good idea), and simply do as close to a 1:1 replacement where required (which for cross-family ports is everywhere), the port could be a lot faster. But it is extremely hard to resist that, because the non 1:1 replacement stuff just appears so right.