GNOME Bugzilla – Bug 698501
file browser: should display files in same order as Nautilus
Last modified: 2020-11-24 10:17:55 UTC
When I view hidden files in the gedit file browser, they may be listed in a different order than Nautilus would use. For example, the file browser lists these files in this order: bar foo bar~ foo~ But Nautilus lists the same files in this order: bar bar~ foo foo~ For consistency, these should be the same.
Created attachment 246859 [details] [review] Fix sorting files in file browser Hidden files were always at the end which is not the expected behavior and conflicts with the behavior of nautilus. If one does not wish to see hidden files they should instead use the filter.
Review of attachment 246859 [details] [review]: Looks good.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
It appears that the order is still not consistent with Nautilus. I'm running gedit 3.10.1 (which includes Garrett's change above). In the file browser files beginning with '.' come before files beginning with [A-Za-z]: .cache/ .config/ .local/ bin/ Desktop/ Documents/ .bashrc foobar In Nautilus (in git master) these files appear in this order: bin/ Desktop/ Documents/ .cache/ .config/ .local/ foobar .bashrc Reopening.
Created attachment 336992 [details] [review] filebrowser: Sort files starting with a '.' like Nautilus Do the same behavior for '#' as well. See: https://git.gnome.org/browse/nautilus/tree/src/nautilus-file.c#n88
ping, can I get a quick review for this patch?
Review of attachment 336992 [details] [review]: Looks good to me.
Mass-closing of all gedit-plugins bugzilla tickets. Special "code" to find again all those gedit-plugins bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.