The Win

Essentially what I want for Gnome 3.0 is what Tomboy just got: a web interface called Snowy. Part synchronization, part collaboration, all “cloud” for those buzzword minded among us.

The Fail

Luckily there’s already Conduit which I think does the synchronization bit… I say “I think” because I’ve never actually gotten Conduit to work. I drag & drop F-Spot onto the canvas**, neat. I drag & drop Network to the right of F-Spot, neat. Now what? There’s no configure option for Network. Heck, there’s not even a Remove*** for Network. I right click and select Synchronize in hopes it will prompt me for details, but instead it happily reports synchronization is finished. Huh?!

I poke around in Preferences hoping for guidance on how to sync to another computer over a network. Wow. The first tab is fine, but the other 2 tabs are just long lists of text. Wait a second, if you scroll horizontally to the right in the Data Providers tab you can see a checkbox to load/unload them! Why you’d want this option other than for development, I’m not sure, but its there if you know where to look.

At this point Conduit has failed to gain my trust, so I give up. I’m fine with Pidgin being crash happy or Eclipse being ridiculously complex to configure. The former isn’t mission critical and the latter is intended for developers.

However, I’m expected to entrust all of my files to Conduit. Files and account information for network resources if I could figure out how to get that to work. I have pretty high expectations for anything I’m entrusting my files and passwords too. Right now Conduit seems more like a demo of GTK+’s canvas drawing abilities (it is pretty looking) than a powerful synchronization tool.

The Dream

My expectations for web enabling Gnome are insanely high. Synchronization isn’t enough (although it’d be an excellent start). I need web enabled collaboration features as well. I need it to Just Work™ as well as be Secure By Default™.

This means:

• All applications can synchronize their settings and data.
• All data has some sort of web viewable format and ideally a way to interact with it on the web as well.
• By default all settings and data should be private.
• Fine-grained CRUD permissions for all settings and data. The Create and Update are key here: not only should I be able to give other users the ability to edit my files but Grandma should be able to upload photos to my photo album.
• While I’m dreaming can I add versioning support (like Dropbox)? Cool, thanks.

The Implementation

Unfortunately I think Conduit is the wrong way to go. The concept is sound, but Worse Is Better™: each application needs to be allowed to implement their own integration with the cloud synchronization and collaboration system. There’s too many application specific tasks to accomplish intuitive synchronization and collaboration features outside the main application.

Tomboy has had pretty good synchronization for a while now. Firefox is getting it with Weave.

In a way F-Spot and Banshee support 1-way synchronization and collaboration. F-Spot can upload photos to a variety of services which have all (or at least most) of the features I’m pining for. Banshee’s ability to download Podcasts and music synchronize to iPods (note: I’ve never used that feature) is a sort of primordial synchronization. If only Banshee Web had survived (and wasn’t written in ASP.NET, the ickiest of all webdev platforms). Abiword has been toying with cloud services for a little while as well.

Perhaps Evolution is the poster child for this: I currently use it as a Gmail and Gcal interface sometimes because there are certain use cases for which I prefer it (shocking I know!). Despite its past reputation for being bloated and buggy, it Just Works&tm; these days and integrates beautifully with the rest of the Gnome desktop (are those calendar events in my system tray calendar?! amazing! Pidgin integration?! <3 Evolution). Evolution lives completely in the cloud and synchronizes everything locally beautifully (after years and years of effort).

Why Gnome Can Do It

Gimp is actually the first Gnome app to really make me realize working on the web can and should be as easy as working locally. All it did was utilize Gnome’s VFS to edit and save images via FTP or SSH. With Gnome’s screenshot tool, I can save a screenshot to a web accessible location in 1 keypress and 2 clicks. Amazing! Thats almost as fast and easy as using a pastebin tool on the command line for sharing text.

Snowy seems like an excellent poster child for the web interface I’m whining about. I haven’t used it yet, but the very idea that Tomboy already has an open source reference implementation is an excellent start. 3rd parties could implement the protocols and offer competing services.

In an ideal world this would create a revenue stream for open source applications: services like Dropbox could support the synchronization and collaboration protocols and in return support development of the projects. The more people who use apps that integrate seamlessly with Dropbox, the more people who pay for Dropbox… or box.net or Amazon or… you get the idea.

FreeDesktop.org Does What?!

That’s right, FreeDesktop.org needs to lead the charge here. Its not enough that the protocols are open, application developers need libraries to make synchronization and collaboration easy. In that way Conduit is right: each application should not completely reinvent the wheel.

FreeDesktop.org needs to follow Mozilla’s lead. Mozilla realized early on that in order for their browser business to succeed, they needed open standards to succeed. FreeDesktop.org needs to do the same. A KDE application should be able to synchronize to the same service as a Gnome app (this is where Conduit’s monolithic-master-synchronization-app model seems too optimistic to succeed). OSX and Windows apps should be able to use the base synchronization libraries as well, even if they don’t use GTK+ or QT.

At the end of the day I should be able to sync my photos, documents, and mp3s between my laptop, desktop, cell phone, Kindle, etc as well as any relevant application settings (Tomboy for Kindle?! yes please!). …and so much more.

* Not always true. For example: posting opinions on a piece of software long after the roadmap has been made.
** Strike 1 against Conduit: “Canvas” isn’t a very end user friendly term IMHO. A minor complaint, but as confusing as the UI already is, it needs all the help it can get. Perhaps the problem isn’t the name “Canvas” but rather that the fact that it doesn’t even need to be said. Remove all references to it and just put a textbox that says “Drop data providers here.” when the canvas is empty. The “Clear canvas” option can just be “Clear” as there’s really only 1 thing that can be cleared.
*** Strike 1.5: “Remove” would be better than “Delete”. Delete makes me wonder if its going to erase my files! Remove seems more descriptive and precise. Also, drop “item” from the end of each right click menu option. Its redundant when every option operates on the item you clicked.

Enter Dropbox: a service for synchronizing files between computers. It works great in Gnome (Windows and Mac OSX as well).

I use Dropbox for synchronizing my Tomboy notes by telling Tomboy to synchronize to a Local Folder: ~/Dropbox/Tomboy

My one gripe is that you have to go into a note to synchronize. Someone has filed a bug and submitted a patch, so hopefully it will be fixed soon.

Gnomers have been discussing DVCSes a lot lately, and at least one seems to prefer bzr as the repository format and git as the protocol it speaks. If this sounds like madness to you, you’re not alone.

What I don’t understand is why more people don’t choose to keep Subversion as their repository and just use the $DVCS-svn of your choice?

Granted I’ve only used bzr-svn a bit, but it worked quite well and seems to only be getting better. I hear git-svn is quite good as well (but iirc hg lags behind the competition).

The benefits of this seem pretty nice:

• Repository and Project management tools could get by with only first class Subversion support.
• Directing inexperienced users to download code would be standardized.
• Linux distributions wouldn’t have to ship 5 different VCSes (cvs, svn, git, bzr, hg), although the VCSes don’t take up much space.
• Developers could use whichever tool they preferred, publish branches to any one of the zillions of free hosts for their DVCS of choice, and get on with their life.

Answering my own question…

The obvious counter argument is that in order to share code you either:

• …force everyone who cares to use your DVCS.
• …or lose some of the benefits of your chosen DVCS and share code via a SVN branch.

Lets face it, both options are a pretty big hassle for developers. Comprises always are.

For smaller single projects the overhead associated with going this route probably isn’t worth it. You’ll probably either end up losing 75% of what makes a DVCS handy or just use SVN.

Why is Gnome not considering this option though?

This option seems ideal for projects like Gnome. Individual modules will probably adopt a preferred DVCS, and thats fine. None of them are so different that a competent developer couldn’t yank some revisions from an unfamiliar DVCS.

The project as a whole (and individual modules) would continue to remain uniformly easily available through a single svn checkout.

At the very least isn’t this better (at least saner) than bolting git onto bzr’s repository format?

Audience Participation

I’m not a Gnome developer though. Just a curious user. However, as a fellow developer I am left wondering: why isn’t this a good option? Are $DVCS-svn connectors just not good enough? Are the comprises too great? Or the most likely: am I just missing some obvious showstopper?

Luckily the fix is easy:

1. Open Applications > System Tools > Configuration Editor**
2. Navigate to apps > notification-daemon
3. Edit the popup_location to be something less annoying. I prefer top_right.
4. Close Configuration Editor. Changes will take effect next time you login or just restart the notification-daemon:

   ~$ killall notification-daemon
   ~$ /usr/lib/notification-daemon/notification-daemon &

Note that the notifications will actually show up over the top of your panel which seems a bit strange. However, I’d rather the notification covered the panel than take up any more precious application space than is necessary.

Luckily you can easily test notifications if you have Python and python-notify installed:

>>> import pynotify
>>> pynotify.init('foo')
True
>>> pynotify.Notification('foo', 'bar').show()
True

* at least on Gnome 2.22.3 on Debian Sid with notification-daemon 0.3.7-1+b1
** aka gconf-editor from the gconf-editor package which should be installed with Gnome.

#!/usr/bin/env python
 
import pygtk
pygtk.require('2.0')
import gtk # sets app name
import gnomekeyring
 
def hack():
    for keyring in gnomekeyring.list_keyring_names_sync():
        for id in gnomekeyring.list_item_ids_sync(keyring):
            item = gnomekeyring.item_get_info_sync(keyring, id)
            print '[%s] %s = %s' % (
                    keyring, item.get_display_name(), item.get_secret())
        else:
            if len(gnomekeyring.list_item_ids_sync(keyring)) == 0:
                print '[%s] --empty--' % keyring
 
if __name__ == '__main__':
    hack()

Sample output with the interesting bits removed:

[default] Local password for user root = *******
[login] michael.schurter@Work = *******
[login] Google Account = *******
[login] Passphrase for wireless network 2WIRE939 = *******
[login] Unlock password for default keyring = *******
[login] schmichael@twitter.com = *******
[session] --empty--

Its not meant to be any sort of real hacking tool. After all you can view all of this information via Seahorse anyway.

But what fun is a GUI tool?