GNOME Bugzilla – Bug 765087
Inconsistency between sorting/icon sizes in nautilus and the save/open file dialog
Last modified: 2017-09-18 19:15:49 UTC
The nautilus hoice of icon size differs from the icon size in the open/save file dialog (file picker) and the sorting uses a different pattern that makes it inconsistent: - nautilus shows folders on top, then hidden folders, then files and last hidden files... - the file picker, the open/save dialog shows hidden folders on top (as they start with a dot which is sorted before any letter) followed by the visible folders then hidden files and then files yes, one can hide hidden files in both cases and then it sorts the same but as soon as you have to open a hidden file/folder it's a completely different sorting which leads to a lot of aimless scrolling. It's just inconsistent. There should be one sorting logic used system wide I guess... The different icon sizes add to the unfamiliarity, - even more with themes that use different icon sets for different sizes (like breeze-gtk) for example. Also I like to add the fact that the left panel in both cases seems to use hardcoded icon sizes which defies the possibilty to use larger fonts effectively (which I need for example as I have accessibility issues)... here it would be greatly appreciated if the icon sizes of the left panels can be chosen like the ones within nautilus (or for starters just use the same setting...). thx for reading, piedro
Is this not the right place for these bugs? No one here? p.
(In reply to piedro.kulman from comment #1) > Is this not the right place for these bugs? > > No one here? > > p. Yes, you are in the correct place
Please, where to report the bugs for the file picker dialog? This is clearly not a nautilus issue. But as we are here now: Is there at least a workaround? - a bit more information/documentation would be very helpful here: 1. Where is the icon size of the open/save - dialog or file picker specified? 1.a) How can I change it? 2. Where is the sorting order defined? 2.a ) As I learned nautilus uses the same sorting as "ls" - how can I force the file picker dialog to do the same? 3. Also: Shouldn't the file picker remember the last location picked? It is really not very user friendly to save attachments of multiple emails (just an example) and click through the whole path for saving the file every time again though there are twenty attachments all going into the same folder... yes, you can create a bookmark but still... Please move this to the correct bug tracker if no one here is working on this file picker dialog - or whatever it is called. Thx, piedro
PLease could someone forward this report to the people working on the "file chooser dialog" - otherwise this will be lost... Please, if it is not part of nautilus what is the correct place for this bug report? p.
Hi, Piedro. A tip for the future: one issue per report. Reporting many different issues at once makes the single report really long and hard to follow. That may explain why nobody has managed to get the time to carefully read and reply here. * 1st issue: icon size differs. I'm not sure what you mean, but file choose doesn't have an icon view yet and there is a bug report about that: bug 141154. If this is not what you mean, feel free to file a new bug report ( Product: gtk+ ─ Component: Widget - GtkFileChooser ) * 2nd issue: Sorting of hidden files is inconsistent: nautilus does not use the same sorting as "ls -a" but I think that would probably be a good idea and then the file chooser should follow that too. This is a known bug and there are reports for both nautilus and gtk+: bug 636526 and bug 587040. * 3rd issue: left sidebar hardcodes icon size: I can't find a bug report about this. Accessibility is important in GNOME, so can you file a new bug report about this please? ( Product: gtk+ ─ Component: Widget - GtkFileChooser ) * 4th issue: file chooser doesn't remember last location: it depends on the application invoking the file chooser. The email application can remember where you saved the last attachment and launch a file picker in that folder. Even if the application doesn't, you can find recently used folders in the "Recent" list on the left sidebar. I hope I covered all your points. This bug report is not very useful as it is, so let's close it, but please feel free to report any further bugs you find. Important: one report for each bug. *** This bug has been marked as a duplicate of bug 679334 ***
THx for adding to the mainb tracker. p.