Nautilus gio-branch merged – be careful

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

File operations in nautilus-gio and adventures in the land of PolicyKit

This week I’ve been working on adding file operations to the gio-branch of nautilus. Today I finished enough to hook up a mostly finished copy operation into the UI. This is completely new code, since gio doesn’t have the gnome_vfs_xfer API that implemented complicated file operations in gnome-vfs.

So, while this is doing the same thing as the old code its structured in a completely different way which is much nicer to work with. And along the way I made some other changes that was easy to do with the new improved design. Check out this screencast of the new features:

nautilus-gio-copy.png

Next week I will continue working on the rest of the file operations. It will be a lot easier now that the general structure and a lot of common code is written.

Also, next week I will be starting to merge libgio from the gio-standalone module into the glib module (as a separate libgio-2.0.so). The gio code has all features required by nautilus (as we can see from the almost finished port), and has been pretty API and ABI stable for a while. So, this is a good time to merge it and get more people looking at the code and using it in their applications.

PolicyKit vs Nautilus

But all that is not whats got me most excited right now. Instead its this idea I got about using PolicyKit and gio in order to implement system administrator features in Nautilus. Basically, you’d do a file operation on some system file, which gives you an error dialog saying you don’t have permissions to do this. But the error dialog has a button that lets you authenticate (with e.g. the root password) and continue the operation with root rights.

This is quite simple to implement in nautilus-gio, because all I/O operations go through the GFile interface. You just create an implementation of GFile that proxies all operations to a setuid helper program (which uses PolicyKit to authenticate). With this done, all the Nautilus code will work unmodified with this new backend, all you have to do is make sure it uses this new GFile implementation.

This is much better than running your entire Nautilus process (or even desktop) as root, for multiple reasons. First of all your Nautilus application will integrate nicely with your desktop (using your theme/prefs/etc instead of the root ones). Secondly a lot less code is running as root, which means that the risk for a security breach or accidents as root are much smaller. Third, you can configure this to use sudo-style authentication which means you don’t need to give out the root password (or even have one) .

Still, this work will have to wait, as the main priority right now is getting the gio-branch into a useful shape so that it can be merged into svn HEAD. I think this will happen soon. Maybe next week even.

Last gnome-vfs symbol gone!

The nautilus gio-branch today reached a major milestone. There is now zero references to gnome-vfs symbols in the nautilus binary. This was accomplished by disabling parts of the file operations code in nautilus, so the resulting nautilus can’t actually do some operations. However, all the file browsing and launching code is working.

At this point we’re getting close to a state where we can get people to start testing the new codebase, and thinking about how to integrate it into Gnome 2.22 and glib. To get this going, and to get more people involved with gio I’ve started a wiki page listing some of the things that remain to do in the various levels of the gio stack.

Consider this a call for action. If you’re interested in this, please take a look at the gio APIs, try it out, and if you’re even more adventurous, pick something from the TODO list and start working on it.