3 ms·

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

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.

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.