GNOME's Nautilus Could See Big Improvements, New Image Viewer Coming Into Focus

[jacob]

Integrating the file chooser with nautilus WOULD be a great step... if in the same process they didn't announce their intention to revamp nautilus UI to be mobile-like and make the whole think could-centric.

[jacob]

To be fair, XFCE's Thunar is even slower than Nautilus when doing a large number of I/O operations. Nautilus is especially bad at rendering previews because it keeps changing the size of the viewport, forcing the window to scroll randomly, making it hard to select anything before it's 100% done.

To be fair, many people don't realise how difficult and complex it is to make a good file manager, if the expectation is (as it should be) that it would work in all corner cases, be fast, always responsive no matter the number of files or directories, be able to copy or move even 50 files of 60Gb each with 100% reliability and without crashing or arbitrarily erroring out, (99.999999% is not acceptable in this case), give accurate and intelligible error messages in legitimate cases (permission denied, disk IO error etc), have an efficient and user friendly user interface etc., support SMB, Webdav, SFTP, etc. with automatic local service discovery, handle authentication, etc etc etc., handle removable devices in a user-convenient way (not just expect the user to mount them manually in /some/arbitrary/path), etc etc.

The fact that the FOSS world still can't get quite right is revealing of the difficulty of the problem, although IMO Nautilus and Doplhin come close. Not as good as Apple's Finder, but probably reasonably comparable to Windows Explorer in terms of user experience.

[caligula]

The fact that the FOSS world still can't get quite right is revealing of the difficulty of the problem, although IMO Nautilus and Doplhin come close. Not as good as Apple's Finder, but probably reasonably comparable to Windows Explorer in terms of user experience.

Well, the usability problem of scroll bar position jumping constantly, making the window unusable, is pretty much limited to GNOME/Nautilus. I haven't seen it anywhere else. I'm actually quite surprised because I don't think the old GNOME 2.x had that problem. It's 100% a frontend UI problem. I/O operations are much more complex.

[jacob]

Well, the usability problem of scroll bar position jumping constantly, making the window unusable, is pretty much limited to GNOME/Nautilus. I haven't seen it anywhere else. I'm actually quite surprised because I don't think the old GNOME 2.x had that problem. It's 100% a frontend UI problem. I/O operations are much more complex.

Yes I agree and it's weird because I also think it's a new bug. But at least Nautilus (gio actually) handles the IO operations fairly well. That's where most if not all personal filemanager projects fail.

[caligula]

Yes I agree and it's weird because I also think it's a new bug. But at least Nautilus (gio actually) handles the IO operations fairly well. That's where most if not all personal filemanager projects fail.

That might be true. I haven't done real benchmarks Nautilus vs command line tools, but I'm pretty sure the GUI status controls and windows require some extra computation. Especially when doing large number of I/O ops, the number of system calls might grow by a certain constant factor because the GUI needs to resolve things like file names, dates, and sizes, when the command line utility is able to perform with file descriptors and pointers only.

For example, many GUI tools usually want to build a list of files for a certain operation. E.g. when deleting all files in a folder. It also wants to sort this list the same way it's listed in the GUI view. This consumes a lot of time when the command line tool can just start the operation in any arbitrary order. The command line tools might even accidentally delete new files that appeared after the operation was started.

[jacob]

That might be true. I haven't done real benchmarks Nautilus vs command line tools, but I'm pretty sure the GUI status controls and windows require some extra computation. Especially when doing large number of I/O ops, the number of system calls might grow by a certain constant factor because the GUI needs to resolve things like file names, dates, and sizes, when the command line utility is able to perform with file descriptors and pointers only.

For example, many GUI tools usually want to build a list of files for a certain operation. E.g. when deleting all files in a folder. It also wants to sort this list the same way it's listed in the GUI view. This consumes a lot of time when the command line tool can just start the operation in any arbitrary order. The command line tools might even accidentally delete new files that appeared after the operation was started.

Actually the GUI handling doesn't really have any effect on it because IO is obviously processed by background worker threads. Note that even that hasn't been a given with many of the primitive Athena/Motif based file managers that would simply freeze while IO operations were underway, and they didn't seem to realise that that was not right. But GIO itself is a sophisticated IO engine that takes advantage of the modern kernel features like splice, vmsplice and tee (the system call, not the shell command). I think it also plans to use io_uring and do async operations, if it hasn't implemented it already. In comparison, most "alternative" file managers as well as virtually all command line tools are comparatively dumb, they just do a while(not_everything _copied) { read(); write() } loop.