Work on the Nautilus gio-branch continues. We’re now down to 203 gnome-vfs calls in nautilus (803 initially) and zero in eel (92 originally). Now, 203 calls still sounds like a lot, but lets take a look at what uses gnome-vfs:
1 libnautilus-private/nautilus-file-operations-progress.c
3 libnautilus-private/nautilus-file.c
4 libnautilus-private/nautilus-program-choosing.c
126 libnautilus-private/nautilus-file-operations.c
3 libnautilus-private/nautilus-vfs-utils.c
5 libnautilus-private/nautilus-file-utilities.c
9 libnautilus-private/nautilus-dnd.c
7 src/file-manager/fm-tree-view.c
4 src/file-manager/fm-icon-view.c
1 src/file-manager/fm-directory-view.c
1 src/file-manager/fm-error-reporting.c
8 src/file-manager/fm-directory-view-old.c
5 src/nautilus-main.c
1 src/nautilus-window-manage-views.c
23 src/nautilus-connect-server-dialog.c
Almost all of it is in nautilus-file-operations.c, which is the implementation of things like copying/moving files, and displaying progress and other dialogs for that. This is certainly very important functionality, and it will be a bunch of work converting it, especially since it heavily uses the gnome_vfs_xfer API, which (thankfully) doesn’t exist in gio. But apart from that almost all gnome-vfs use in Nautilus is gone
I’ve also cleaned up the code in several places, removing crufty, old and unused code, in places replacing it with more modern Gtk+/glib functionality. Eel especially has dropped a lot of code. Lots of creds go to Paolo Borelli who has done a bunch of work on this.
On a slightly more end-user interesting tangent, today I updated the fuse code that hpj wrote (it had stopped working due to some internal changes) and integrated it with the gvfs backend for libgio. This means g_file_get_path() will now return a local fuse path even for non-local files. In practice this mean applications that do not access files via gio can still load and save files on e.g. remote shares like smb, ftp, sftp, etc.
I made a screencast to show this off. Check it out!
Great work! đ
Ser fram emot det hÀr slÀppet. Framförallt att kunna lÄta program som inte Àr GNOME-integrerade öppna filer pÄ t.ex. en SMB-share.
What’s the net gain of removing gnome-vfs?
im not worthy, im not worthy
Please let me have your babies.
Love, Ross
Really nice. Are things like FTP also working well. I the past when I used gedit to edit my website on an ftp server gedit hang when the ftp connection is slow. It becomes responsive again when everything is loaded and saved from the ftp server.
I also miss restoring files in the trace as windows have. I switch my girlfriend to Linux and se complains about that.
Ross: My babies are not for sale!
dr88dr88: Ftp is not implemented yet.
Could http://bugzilla.gnome.org/show_bug.cgi?id=167501 be fixed as well? There’s a patch against 2.20, could it be savaged and adapted to gio?
Awesome!
Is there any chance of unifying this with KDE’s thing. Something like this seems relatively desktop-agnostic, and it would be great if GNOME and KDE’s implementations of this sort of thing were compatible.
Really nice looking!
I suppose there is a tar method like with current gnome-vfs? What happens if there’s a tar file in the samba mount? will there be a second mount point for the tar file under .gvfs/ ? Will Nautilus be able to browse up and down into the tar file?
nona:
There is no support for chained uris like there is in gnome-vfs. That model is complicated and never quite worked well in gnome-vfs. Also, I think it generally will be a better user interface if a dedicated app like file-roller handles archives.
Can you shed any light on the most frustrating issue with any fuse-based network mount and nautilus being that files are treated as *local* and thus prompting to nautilus to preview them ? (Besides them being relatively slow and tending to simple hang-up in certain situations)
If I remember correctly this issue (nautilus not always guesses “correctly” if a file is actually on a local harddisk or accessed remotely) was discussed in a mailing list or so in quite some detail a while back.
Besides that: Rock on !!!
Will this be in 2.22?
a foo:
That is the plan at least.
Matthias Adler:
Various people have ideas how to solve this.
The best solution I’ve heard involves adding a mount option like “udata” this would not be handled by the kernel, but just echoed back in /proc/mounts. Then you can set mount options like -o udata=nopreview,notrash and apps can honor that for this particular mount.
about the “chained uri” thing:
That’s quite a shame! I understand that you feel a dedicated app for archives can be better, but I suppose the same could be said about FTP, webdav or samba (a dedicated ftp client could be better than gvfs ftp: method).
I personally like the consistency URI chaining gives, and I use it all the time (really!) with the Midnight Commander (ssh+tar+gz+…). I was hoping the mc would one day be able to migrate to gvfs, but it would be a shame that it would cost them a nice feature.
That said, I realize you probably got a very good insight on what a vfs should be like considering Nautilus’ heavy use of it. I just regret this one feature.
nona:
I even got a recommendation from some of the kde people to not support it, as they had a lot of problems with it…
In a modern environment, the most common use-case of an archive file, by far, seems to be to download an entire folder structure conveniently from the internet (Witness archive files full of things like .jpegs and .mp3s– which don’t compress much, if at all.). XP’s more folder-like treatment of archive files has struck me as one of the features worth imitating if at all possible.
That is awesome! Rock on Alex…