The Plug-ins, They Are A-Changing

One of the things about the 2.14 deskbar-applet release was that, although it supported third-party plug-ins, the GUI to manage them was all-but-nonexistant. Basically, whilst you could enable and disable installed plug-ins via the checkboxes in the preferences dialog, you couldn’t (a) find and install new plug-ins, and (b) update existing plugins through the GUI — both of which Firefox lets you do, for example. Instead, you had to download a file (or download and unpack a tarball) and copy that to a secret directory (~/.gnome2/deskbar-applet/handlers/) — i.e. one that you couldn’t find in nautilus.

In the last few months, Sebastian Pölsterl and the other deskbar hackers have worked on being able to install new plug-ins through a friendly GUI. The deskbar-applet-list mailing list discussion starts in April, continues in May and there’s also the PluginManager wiki page. Here’s the current state of play (no, this isn’t finalized, yes there are issues, which I’ll touch upon at the end of the tour). First off, there’s a new Check For Updates button on the list of installed plug-ins.

Clicking on that invokes the NewStuffManager a new (Python) program that communicates with deskbar-applet via D-Bus. To be precise, NewStuffManager provides the org.gnome.NewStuffManager service. NewStuffManager is not deskbar-applet specific, and could provide any app with update info. The app-specific part is another Python file, deskbar-applet’s spec is the only instance so far, and looks like this:

"repo": "",
"install-path": "~/.gnome2/deskbar-applet/handlers",

And note that it mentions, which is the master list of plug-ins and their versions. The intention is that distros can customize this URL, if they choose to. An example snippet of that XML file looks like this:

<name>Yahoo! Search</name>
<description>Search Yahoo! as you type</description>
<author>Deskbar Team <></author>

NewStuffManager will note that there is a new version of the Yahoo handler, and the UI will show that it is updatable.

Clicking on Update will show a progress dialog box, and under the hood, download the newer from, unpack the archive (if necessary), and copy those files to the right place in the file system: ~/.gnome2/deskbar-applet/handlers/. Note that this is the user’s installed plug-ins, not the globally-shared (and only-writable-by-root) plug-ins at /usr/lib/deskbar-applet/handlers.

The other thing to notice is the New Extensions tab. Switching to this tab will invoke NewStuffManager to check the master list for installable plug-ins. It looks like this:

Again, the Install button will download and install the plug-in. There really isn’t much difference between updating existing plug-ins and installing new ones, apart from that the user was (probably) aware of an existing plug-in beforehand, and updating an existing plug-in might involve an active existing plug-in.

That’s what it looks like. It is indeed easier to find and install plug-ins than before. And plug-ins rock, since they make users go, “I rock”. However, there are two very significant issues:

We will be downloading arbitrary Python files, which could be executed whenever the deskbar-applet initializes all of its plug-ins. This could be a major security hole. Personally, it’s not that I don’t trust Raphael or his web-site, or the third party websites that he chooses to endorse, but I don’t trust (the worst of) the internet. We don’t have digital signatures or other verification mechanisms implemented yet (and GNOME 2.16 is due only a few months from now). Auto-update (and auto–removal of obsolete files) is another issue that should be considered – whilst it is frustrating as a developer that users don’t manually upgrade to the latest and greatest, users should remain in control of their computers. Possible precedent / discussion point: Firefox auto-updates (IIRC).

This design means that (or whever the master list(s) get hosted) is pinged every time I look at the New Extensions tab. Possible precedent / discussion point: distros already provide updates, automatically, over the internet.

Clearly, dropping this feature onto millions of GNOME 2.16 users is not a decision to be taken lightly, and I think that to-date the discussion has been on too narrow a forum — the deskbar-applet-list (and the ephemeral IRC) rather than to the wider GNOME community, and I have procrastinated far too long on putting forth my thoughts on this matter. I’m just about to post to desktop-devel-list as soon as I publish this blog post. Join the discussion there, if anywhere.

Two final things – this is not a definite feature of GNOME 2.16 yet, this is a discussion of an unstable version, a work-in-progress. Because I’d hate to be misunderstood. 🙂

Secondly, Sebastian, Mikkel, Raphaël and others have already sunk a lot of time into this, and I’d hate to sound like I don’t appreciate their work, their enthusiasm, their contribution, and their intentions. I do. 🙂 And like Mikkel said: “I really think it’s a cool feature; I would just hate to botch it“.


#1 Gnomie on 07.31.06 at 8:29 pm

I just like the idea of NewStuffManager, it would be needed across all GNOME (gedit plugins, nautilus plugins,etc..), because GNOME has simple defaults, we have to offer an easy way for our users to *discover* and extend the functionality of the default desktop.

But for NewStuffManager to be used GNOME-wide I think it should be written in C, because this is more an api than an application…

#2 john on 08.07.06 at 4:45 pm

Should this not be tied in some way with the distributon package manager?


#3 David Nielsen on 08.07.06 at 5:33 pm

The security issues with this boggles my mind, honestly this is what I have a distro vendor for, they package and sign these things and I get them installed using the same coherent interface with good security since I trust, in my case Fedora.

Isn’t that considered one of the many boons of free software, we don’t have to experience the multiple points of entry for updates that you do in Windows. The pain of having 10 billion different little programs all serving the same update use case but for their product only is just hell, we really should be careful to not encourage the same thing with GNOME.

Trust your vendor, they trust upstream – you get the lastest and greatest with no hassle what so ever.