[hedora]

Have they fixed the file chooser yet?

Specifically, I want to be able to click around on directories to choose where to save a file, type the file name, then press enter. This should save the file, not filter the directory listing.

Also, I don’t want it to default to overwriting some file I saved last week.

[superkuh]

No. I actually went to GNOME's IRC network the other day to talk to them about gtkfilechooser's multiple problems. Yours, and then the lack of text input for typing or pasting file paths. https://gitlab.gnome.org/GNOME/gtk/-/issues/938 . They said they have no one assigned to gtkfilechooser bugs and none will be addressed.

I was able to download the debian source for a couple gtk applications (ie, gedit/pluma) and apply community sourced patches to them to get back the text/file path entry box. But there's no way I am going to be able to fix Gtk itself. And fixing every application on my system by compiling from source and making new debian packages, well, I might as well linux from scratch.

[swiley]

I'm glad to hear putting hamburger menus in all the window title bars is prioritized over having a functioning UI.

[hda2]

This has been going on for a long time now and is to be expected. My real problem is that they completely remove existing functionality from UI without giving the users who relied on it any alternative.

[nerdponx]

Purely out of curiosity, what else is the Gtk team currently working on? People have been complaining about the file chooser for years.

I'd be willing to donate a good chunk of money just to support "basic UX" improvements to FOSS software and toolkits like Gtk.

Should we start a "Fix the Gtk file chooser" Gofundme?

[turminal]

> Purely out of curiosity, what else is the Gtk team currently working on?

Probably redesigning the entire interface. "For your convenience".

[merb]

which they also do for years.

[TingPing]

The GTK team is like 3 people. GTK4 worked on improved cross-platform support, effecient gpu rendering, documentation, sandbox integration, etc.

UI designers are probably limited and there is just a lot of drama about the filechooser so it's easy to find other things to work on.

[hda2]

The patches already exist. In fact, PopOs! already has this feature merged.

[superkuh]

I searched PopOs! repos and I couldn't find where they maintained their Gtk-3.0 patches or code. It didn't look to me like they altered Gtk-3.0 itself at all and likely just altered individual applications.

[bjourne]

Fixing the GtkFileChooser is not the main problem, it is getting your patches merged. Someone from the Gtk team needs to review them and put their stamp of approval on them. But the Gtk team are RedHat employees and they prioritize whatever the company wants them to prioritize. And if the company doesn't want them to prioritize the GtkFileChooser, your patches will languish on their bug tracker. If you are lucky, you'll get a message two years after you uploaded them asking you to rebase them to HEAD because the code base has changed to much that your patches can't be merged without them being significantly reworked.

[ahartmetz]

It's more like decades, not years, by now. Seems worthwhile.

[acqq]

And now everybody should look for a text from 2003 written by jwz mentioning the "Cascade of Attention-Deficit Teenagers model" and slowly read it again, then think how much time passed since.

[nine_k]

Most Gnome developers, I suppose, are on RedHat payroll and are not teenage.

They are busy working on various things, this is certain, and these things are apparently more important for them. Like, well, GTK4.

I suppose most Red Hat customers are corporate, and when they ask for featureful Linux desktop, they likely mean playing nice with corporate systems. This is why Evince is such a good PDF viewer, compared to a lot of others; it can even fill in forms. This is why the file chooser without image preview is fine as is for corporate use, because I suppose that 0% of graphic designers choose a Linux machine in a corporate setting.

[fao_]

> Most Gnome developers, I suppose, are on RedHat payroll and are not teenage.

jwz was not talking about the age, he was talking about the issue of ignoring bugs to the point where they reach decades old, and often even then persist and go unfixed. Some bugs live multiple decades, across three different issue trackers, having to be reopened each time.

The fun fact is that he wrote this in 2003, about the GNOME developers. Not much has changed in 20 years, it seems.

https://www.jwz.org/doc/cadt.html

[locke78]

This article has so little substance that I wish people would stop re-posting it. It adds nothing to the discussion. Like yeah, there are bug reports that haven't been addressed. Developers come and go and sometimes have to leave before they get to work out all the bugs in their feature(s). It happens. Every big open source project is like that. The bug tracker is open so that anyone can submit bug reports. The downside is that it tends to fill up with unsolicited bug reports that don't get responses. The upside is that anyone in or outside the project can volunteer to fix any of those bugs. I don't see JWZ stepping up to triage random bugs in GNOME, probably because he knows it's a thankless job with no pay that he wouldn't enjoy.

[fao_]

> I don't see JWZ stepping up to triage random bugs in GNOME, probably because he knows it's a thankless job with no pay that he wouldn't enjoy.

Thing about it is, it's the responsibility of the GNOME project. It's the responsibility of the developers that sign up to it. Each time GNOME has been improved, old problems still persist. It says something about a project and the integrity of the developers when they claim to increase usability and yet do not bother with longstanding problems.

The root of the problem is a certain mindset to development. One that is numerous and yet flawed.

"Move fast, break things! No time to fix them we have other concerns like- checks notes- revising every system menu to look slightly different. Hell yeah!! Wooh!"

[nine_k]

The idea of "unsolicited bug reports" is lovely.

[mseepgood]

Shouldn't they be in their 30s by now?

[xiaomai]

the main text entry ("Name", the one that starts out focused) lets you type/paste paths.

[hedora]

It loses focus once you switch directories. Restoring focus to the default state involves selecting the filename, but not the extension.

[superkuh]

Not in GTk 3.24.5.

[dasweffar]

I've lurked on HN for more than a decade but created an account to concur with this comment. Accidentally filtering for folders (who even wants this) instead of typing a filename is truly awful and affects me daily. I would bail on gnome for this issue alone if I didn't have to use it on a work machine.

Does anyone know of an issue in their tracker with an official stance on it?

[MarkyC4]

Probably something like[1]:

Because of the release of GNOME $next, and the lack of interest in maintainership of GNOME $prev, the gnome-core product is being closed. If you feel your bug is still of relevance to GNOME $next, please reopen it and refile it against a more appropriate component. Thanks...

[1] adapted from: https://www.jwz.org/doc/cadt.html

[hollerith]

>I would bail on gnome for this issue alone if I didn't have to use it on a work machine.

Both Google Chrome and Firefox use GTK's file picker (at least when "saving link as..." at least on Fedora 34 Prerelease) so what would you do for a web browser?

[yyyk]

>what would you do for a web browser?

If your environment has a xdg portal port (KDE does), you can use the relevant portal. Set GTK_USE_PORTAL=1 , and then firefox uses the native file picker.

[stockerta]

Probably they will deprecate it soon, and gnome apps will randomly open a file for you. Just to be easier to use. A file picker dialog can confuse the user.

[hallarempt]

Well, given that that's what macOS Big Sur has done, it's a dead cert. You no longer get a file picker dialog by default when saving, but a place where you can type a name and a label that says where saving will happen.

[gh-throw]

Where do you see that? I tried hitting cmd+s in Safari, Terminal, and Pages and got a normal macOS file-save dialog in all three cases. Looks more or less the same as it has for quite a while. I haven't touched anything related to file save settings (I probably should, as I'd like the arrow-down-to-browse-files to always be expanded, and I know there's a setting for that somewhere, just haven't bothered to yet).

[e_proxus]

I think they complain about the fact that the file dialog is collapsed by default, going to some length to hide the browse functionality (Apple probably wants you to save everything in Documents and be done with it).

The save dialog can be expanded by default by tweaking it though: https://github.com/mathiasbynens/dotfiles/blob/master/.macos...

[christophilus]

Gnome is my daily driver, and overall I'm a fan. But this is one of the dumbest file pickers I've seen.

[wayneftw]

Agreed 100%. As soon as the dialog opens, I usually just want to start typing the file name to save and then press enter to save.

The workaround is that I must remember to hit Alt+N to focus on the filename box before typing. Usually I forget though.

[amelius]

Also, the file chooser should show previews, like in Nautilus.

[brian_herman]

I also want them to just make it so I can right click and create a new empty file. Linux is file based right? If I right click on a opened folder I want to create a file.

[turbinerneiter]

You can do that, make a folder called Templates and put your templates in there.

Or maybe I'm misunderstanding.

[brian_herman]

I thought that was only on KDE...