5 ms·

New is not better (wayland cannot abolutely position new windows, cannot do mouse keyboard sharing (except via non-standard libei which different waylands rejec

New is not better (wayland cannot abolutely position new windows, cannot do mouse keyboard sharing (except via non-standard libei which different waylands reject, etc). Unchanging is not broken (X11 works just fine, just because it's not constantly getting new code doesn't mean it stops working). The primary features I'm missing focus around the way GNOME developers believe files should be interacted with. They believe the file chooser should be a search interface and making things like pathbar the only option and removing filename-entry, and the entire gsettings for it, are part of this. GNOME developers have drastically changed the GUI for file selection so that typing, pasting, or entering filepaths has been made difficult. Everything has to be done through the automagic "search" (which often bugs out) or mouse interface. This would be fine as defaults, but they've literally removed the former options in gsettings to config a gtk application's behavior. They say these are "private" and we should never have been using them all. All bugs since 2014 marked "wontfix" and community patches rejected. Basically, GNOME is anti-keyboard. I think that the gross changes to Gtk3 over the past 10 years have been minimal and that yes, a group of a dozen people could maintain it in it's static form and prevent further eroding of features. I compile my own Gtk3 with fixes for the gtkfilechooserwidget.c that have been rejected by the Gtk team ("gtk3 is frozen" "filechooser is too much spaghetti, any change fixing one thing would break another"). Maybe even apply some of the many community fixes that the GNOME developers consistent reject and ignore (just look at the Arch Gtk3 fixes patch set). Can they develop and add new features like new renderers and support for Wayland? No, but that is not needed. I don't appreciate you turning this into a personal issue, that's generally against HN tos.

uecker 3y ago
It would be good if interested parts of the community maintained its own fork of Gtk3 and get involved with X development to keep it alive.
jeroenhd 3y ago
Perhaps it's time for someone to fork GTK+3. It's clear that the GNOME guys are beyond done with maintaining old GTK code (and I can't blame them) and the ecosystem for old applications won't move forward trying to patch code in a project that's essentially on hold. It shouldn't be too difficult to fork the project and produce drop-in libraries for projects based on GTK+2/3 with patches applied. Through the desktop portal API, these changes would even apply completely transparently for windows like file pickers. There's such a big online crowd clearly voicing their opposition to the direction GNOME is taking GTK and other software, I don't get why these people don't just get together, set up a website and a forum somewhere, and split off to do the things GNOME doesn't want to do.
- robinsonb5 3y ago
  > There's such a big online crowd clearly voicing their opposition to the > direction GNOME is taking GTK and other software, I don't get why these people > don't just get together, set up a website and a forum somewhere, and split off > to do the things GNOME doesn't want to do. Maybe it's just because fighting against the tide is exhausting. Changing the world is young person's game - you need people with energy, enthusiasm, a vision of a better way and enough capacity for self-delusion to believe that it's actual possible. (My cynical streak may be showing here!) I suspect the "phone first" generation's never going to understand why modern UI fads such as hamburger menus and icons with no clear delineation engender such contempt from us mouse warriors! I'm old enough to remember the pain of moving from GTK+ 1.2 to GTK+ 2. That's when we lost tab-completion in the file picker. (Boy was that file picker ugly, but you could drive it using the keyboard much more easily than anything designed since, without the mouse being a second-class citizen.) There were a few obscure pieces of software which took years to be forward ported to Gtk+ 2 because the original authors weren't around any more. I wrote some software myself against Gtk+ 2 - printing-related - but since I no longer even have a printer at home, I have no interest in updating it for newer Gtk+ - and since it still used Gdk rather than Cairo (because back then Cairo would have made the colour management stuff I was doing impossible - I have no idea whether those limitations have since gone away) - it'd be painful to update anyway. If I had limitless time, energy, and didn't need to earn a living I'd fork Gtk+ myself just to rid myself of hamburger menus (see my earlier comment about not making the mouse a second-class citizen!) In the real world I'm jaded and burned-out enough with tech that I see too much else wrong with modern software, and desktop Linux in particular, to expend much of my life trying to hold back the tide of (what I see as) idiocy.
jl6 3y ago
I believe you are referring to https://gitlab.gnome.org/GNOME/nautilus/-/issues/1157 https://gitlab.gnome.org/GNOME/nautilus/-/issues/1157 - an incredibly longstanding issue that has been raised and re-raised by dozens if not hundreds of users over the years. As far as I can tell, the devs view it as incompatible with a design principle. Sticking to principle is one thing, but this is truly a head-in-the-sand situation.
- teo_zero 3y ago
  This is a clear example of "catch 22" situation: a) we won't implement this change because it's incompatible with the design; b) the design was set 10 years ago and never changed since then, so there's no reason to doubt it's sound.
- deleted 3y ago
  [deleted]
- cardanome 3y ago
  The insane thing is how trivial it would be to support it: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1030/diffs https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/103... Less than 200 lines changed and they act like it would absolutely kill them to maintain it. Even if just 5% of users profited from it, it would be well worth it to support. Yes it adds additional complexity to testing but come on.

uecker 3y ago

It would be good if interested parts of the community maintained its own fork of Gtk3 and get involved with X development to keep it alive.

jeroenhd 3y ago

Perhaps it's time for someone to fork GTK+3. It's clear that the GNOME guys are beyond done with maintaining old GTK code (and I can't blame them) and the ecosystem for old applications won't move forward trying to patch code in a project that's essentially on hold. It shouldn't be too difficult to fork the project and produce drop-in libraries for projects based on GTK+2/3 with patches applied. Through the desktop portal API, these changes would even apply completely transparently for windows like file pickers. There's such a big online crowd clearly voicing their opposition to the direction GNOME is taking GTK and other software, I don't get why these people don't just get together, set up a website and a forum somewhere, and split off to do the things GNOME doesn't want to do.

robinsonb5 3y ago
> There's such a big online crowd clearly voicing their opposition to the > direction GNOME is taking GTK and other software, I don't get why these people > don't just get together, set up a website and a forum somewhere, and split off > to do the things GNOME doesn't want to do. Maybe it's just because fighting against the tide is exhausting. Changing the world is young person's game - you need people with energy, enthusiasm, a vision of a better way and enough capacity for self-delusion to believe that it's actual possible. (My cynical streak may be showing here!) I suspect the "phone first" generation's never going to understand why modern UI fads such as hamburger menus and icons with no clear delineation engender such contempt from us mouse warriors! I'm old enough to remember the pain of moving from GTK+ 1.2 to GTK+ 2. That's when we lost tab-completion in the file picker. (Boy was that file picker ugly, but you could drive it using the keyboard much more easily than anything designed since, without the mouse being a second-class citizen.) There were a few obscure pieces of software which took years to be forward ported to Gtk+ 2 because the original authors weren't around any more. I wrote some software myself against Gtk+ 2 - printing-related - but since I no longer even have a printer at home, I have no interest in updating it for newer Gtk+ - and since it still used Gdk rather than Cairo (because back then Cairo would have made the colour management stuff I was doing impossible - I have no idea whether those limitations have since gone away) - it'd be painful to update anyway. If I had limitless time, energy, and didn't need to earn a living I'd fork Gtk+ myself just to rid myself of hamburger menus (see my earlier comment about not making the mouse a second-class citizen!) In the real world I'm jaded and burned-out enough with tech that I see too much else wrong with modern software, and desktop Linux in particular, to expend much of my life trying to hold back the tide of (what I see as) idiocy.

jl6 3y ago

I believe you are referring to https://gitlab.gnome.org/GNOME/nautilus/-/issues/1157 https://gitlab.gnome.org/GNOME/nautilus/-/issues/1157 - an incredibly longstanding issue that has been raised and re-raised by dozens if not hundreds of users over the years. As far as I can tell, the devs view it as incompatible with a design principle. Sticking to principle is one thing, but this is truly a head-in-the-sand situation.

teo_zero 3y ago
This is a clear example of "catch 22" situation: a) we won't implement this change because it's incompatible with the design; b) the design was set 10 years ago and never changed since then, so there's no reason to doubt it's sound.
deleted 3y ago
[deleted]
cardanome 3y ago
The insane thing is how trivial it would be to support it: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1030/diffs https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/103... Less than 200 lines changed and they act like it would absolutely kill them to maintain it. Even if just 5% of users profited from it, it would be well worth it to support. Yes it adds additional complexity to testing but come on.