GNOME Bugzilla – Bug 568437
Inconsistency : "save as ..." window does not sort files like nautilus do
Last modified: 2017-09-18 20:51:25 UTC
I configured Nautilus so that by default : - files and folders are sorted by modification time - folders are NOT sorted before files It seems that the "save as ..." window has it's own way of sorting files and folders : - always sorted by name - always folders sorted before files This inconsistency is truly annoying for me. Other information: same for "system" files (eg .htaccess). If it is displayed in nautilus then it should be displayed in "save file" dialog also this dialog puts ".*" folders before "*" folders. Annoying.
-> GtkFileChooser
This is obsolete in GTK+ 3, as the FileChooserWidget pays attention to the same GTK+ wide settings for sorting folders/files and showing hidden files as Nautilus, i.e. https://git.gnome.org/browse/gtk+/tree/gtk/gtkfilechooserwidget.c?h=gtk-3-22#n3875 https://gitlab.gnome.org/GNOME/nautilus/blob/master/src/nautilus-files-view.c#L2681 Nautilus now uses GTK+ 3, so this is effectively obsolete. I doubt the use of settings will be backported (if it even can, which I don't know).
This is good news, I guess! So from which versions up will the changes be present? Anyway, thx a lot, p.
(In reply to piedro.kulman from comment #3) > So from which versions up will the changes be present? I don't know when it originally debuted in GTK+ 3, but 3.22 is the maintained version of GTK+ 3, so that one. Again, GTK+ 2 is not, and probably will not be, the same; I don't believe it looks at any settings for these, much less that it would synchronise with current Nautilus.
Sadly, after checking - I am on GTk 3.22.21 and gnome 3.24 on ARCH - the inconsistencies are still there: Open "personal folder" in Nautilus: Documents Fotos Movies ... .adobe .android .baaloon .Backintime-Dummy .bogofilter Open the "personal folder" with file picker in evolution 3.24 or fileroller: .adobe .android .baaloon .Backintime-Dummy .bogofilter Documents Fotos Movies 1. So file picker still sorts hidden folders BEFORE folders no matter whats in nautilus settings. 2. Also sorting settings within the settings dialog of nautilus (like described: e.g. sort by access time...) doesn't change the behaviour of the file picker in any way it seems... it's still sorting folders first! 3. Also the size of the icons in the file picker is always the smallest no matter how it's set in nautilus - this is annoying as the smallest size icons use a completely different pictogram for some obscure reasons in most symbol sets... very hard to quickly recognize that it's the same - even worse on big screens or with problems with the eyes... So please reopen... and maybe ginform a developer. Or am I missing something here? Have you tested the behaviour? Isn't it the same behaviour for you? I get all the inconsistencies above even if I use the "back to defaults" button in nautilus settings... Not happy, hmmm, p.
Also: - hiding files in nautilus can be done by clicking on the "hamburger" menu button in the top right - the file picker dialog doesn't have that button, you have to rightclick somewhere to open a context menu So not files are: - sorted in a different pattern - shown in a different visual style - they are also handled with a completely different user interaction I really do not get why this not handled properly - in other areas of the UI Gnome is insistent, sometimes even obsessed with consistency. And the most basic interaction with files is such a mess... (and has been for 10 years. well, sigh, p.
Please keep this thread for the one issue you opened it for, and see Bug 679334 for the tracker of various other inconsistencies. If you have any new ones beyond the ones reported and linked there (in the Depends On section), please post them as new bugs. Right, the setting sort-directories-first does indeed not seem to work. I just presumed based on the age and presence today of code checking the setting, that it would actually do something useful... reopened. > 2. Also sorting settings within the settings dialog of nautilus (like > described: e.g. sort by access time...) doesn't change the behaviour of the > file picker in any way it seems... it's still sorting folders first! I don't know if this is directly related or was intended to sync up (yet). Maybe it's already discussed on the tracker. (In reply to piedro.kulman from comment #6) > I really do not get why this not handled properly - in other areas of the UI > Gnome is insistent, sometimes even obsessed with consistency. And the most > basic interaction with files is such a mess... (and has been for 10 years. > > > well, sigh, p. It's not handled properly because bugs happen. This and other issues will continue to be "such a mess" for another 10 years if no one writes patches to fix them. Sadly, resources aren't infinite, and don't appear from nowhere.
retitling as show-hidden appears to be OK, at least.
What you mean by retitling as show-hidden? Sry, I don't understand... p.
Created attachment 360008 [details] screenshot of sort-directories-first working Read that "as" as 'because', then you'll get it. (In reply to Daniel Boles from comment #7) > Right, the setting sort-directories-first does indeed not seem to work. ...uh. Yeah, it *does*. Did you quit and restart the app after changing the GTK+ setting? That seems to be required, i.e. the setting is not reloaded dynamically. Please check this and let us know if it works for you now. It certainly should!
(In reply to Daniel Boles from comment #10) > Did you quit and restart the app after changing the > GTK+ setting? That seems to be required, i.e. the setting is not reloaded > dynamically. Hmm, sorry for the spam, but it seems worth it to mention that _now_ it _does_ work for me, so long as I close and open the filechooser, not the entire app (in my case, GEdit). But check the latter too if the former seems insufficient for you.
Ah, thx. The "hidden" setting transfers to the picker... > (In reply to Daniel Boles from comment #7) >> Right, the setting sort-directories-first does indeed not seem to work. > > uh. Yeah, it *does*. Did you quit and restart the app after changing the GTK+ > setting? That seems to be required, i.e. the setting is not reloaded > dynamically. > > Please check this and let us know if it works for you now. It certainly should! You are right. One has to change the setting in one of the two applications and close both (!) of them before reopening and Tada! Though this probably should be dynamically applied like all other settings in gnome behave. But at least for now the setting transfers... That's good. p.
No, you are right, you do not have to close both applications but only nautilus and the file chooser dialog. Depending on where you aplly the setting: - change in nautilus will change the Chooser after restarting the chooser (not the app) - change in the chooser will change the setting in nautilus also after closing the choser, restarting nautilus has no effect This let's me guess that - the file chooser reads settings on start and writes it's setting on closing. - Nautilus on the other hand seems to apply the settings dynamically Same for you, right? thx for taking the time, p.
Thanks for the confirmations! (In reply to piedro.kulman from comment #12) > Though this probably should be dynamically applied like all other settings > in gnome behave. Sure, that's how most settings behave... *if* the dev listens for changes and applies them instantly. :) But nothing enforces that in code, and I'm not aware of a specific design guideline about it. It's certainly handy as a user, though. At present - and as you found since I started writing :) - FileChooserWidget loads its GSettings during ::map (~= show) and saves them in ::unmap (~= hide), which explains why a minimum of closing and reopening the dialog is required. It would be possible to make open FCWs dynamically update when their GSettings change, but I have no idea how likely that change is to be written/accepted - or at least whether it's important enough for the extra code it'd need (avoiding the blunt force of just loading/saving all keys for every change on either side) That'd certainly meet your very fair expectation of instant update, but my guess is usually, people change these in one of Nautilus or the FCW, instead of having both open and changing on-the-fly. The latter may onle happen when evaluating old bug reports. :) So, it'd be worth considering if it's really needed first. So, let's close this one, and of course you can open a new enhancement bug if you like, though again I can't speculate on whether it'll really go anywhere. Thanks for the report and the detailed testing! Sorry that I confused things in the middle for a while. :P
Thx to you too. And I think you are right changing back and forth with open windows seems not a very likely use case to worry about... So before celebrating... isn't there still the issue of: - sorting of dot.folders before visible folders in the GTK-Chooser - sorting of visible folders before dot.folders in nautilus Will this be handled in the other bug report? https://bugzilla.gnome.org/show_bug.cgi?id=679334 Or should I open a new one because it's not a "one issue thread"? ty, p
I missed that one. But yes, the tracker links to 2 bugs, one for each side: https://bugzilla.gnome.org/show_bug.cgi?id=587040 https://bugzilla.gnome.org/show_bug.cgi?id=636526
Thank you a lot! I'll subscribe there then... Also thanks a lot for your efforts, this has been a helpful experience in assessing how entangled these things really are without even touching the technical beef! Cheers, p.