Today I got most of file moving working in nautilus-gio, so that means that most functionality is there, even if its quite raw and not very tested. Its time to get more people involved in testing and working on the new codebase.
So, I just merged the nautilus gio-branch to HEAD.
WARNING: Its still far from done, and it might eat your files. Don’t use in anger! If it breaks you get to keep both pieces.
There is a list of things left todo on the wiki. But even after that is finished there is bound to be a bunch of stuf to be fixed.
So, use with caution, and give feedback.
UPDATE: Please file bugs against the GIO component of nautilus in bugzilla, so we can track this
This “gio” means also that it will be easier to create virtual file systems for Gnome? I have been long wanting to get a virtual svn file system with the ability to sync (commit/update) local versions of parts of the svn in USABLE way. :-/
So, gio will replace totally gnome-vfs and any network folder will be mounted throught FUSE? It’s a good idea unify the backend for all kind of partitions, like USB storages, bluetooth or mp3 players…
Isn’t it?
gio will replace gnome-vfs, but it doesn’t use fuse for file I/O like you seem to think. However, there is a fuse mount that lets standard unix apps access gio via the standard filesystem.
Can gvfs mount partitions like an obexfs share via bluez or do you need a backend like Gnome-vfs-obexfs (which is extremely unstable btw and also kind of kills nautilus when it hangs).
Björn:
There is no obexftp backend yet, but one is being worked on. It will use bluez of course.
The stability should be better though, as in gvfs the backends run in a separate process, which isolates both nautilus and the backend from each other.
Will this enhance the performance?