Gwibber, or “Planning for Plugins”

I have been consistently pleased with Gwibber as a Twitter client over the past year or so, and I’ve seen some very nice improvements over that time (support for new services like Buzz and Digg, support for displaying thumbnails of Twitpics, etc.). Yesterday I was working on a simple prototype for fetching status updates from a web service, and thought Gwibber would be a good place to integrate it.

While I was (mostly) successful, the experience left me with some questions about plans for extensibility by 3rd party modules for Gwibber. Every service is implemented in its own Python file in a directory, adding the class for a new service was easy. Making Gwibber load it was much more difficult.

Gwibber’s client file explicitly imports all of the service modules. This is a problem: if I want to add my own service, I need to edit core Gwibber files. Not to mention, those files are of course in /usr which means I need superuser permissions to do so, and any Gwibber updates will overwrite those changes. I’m certain that there are “plugin” module loaders out there for Python, and if there aren’t any that are suitable it’s easy to write your own (I’ve done so in the past for a different project).
The second part of that problem is that simply importing the module isn’t enough, I also had to edit a dictionary in the client file to add my service to the list of recognised services.

Success… in some ways. The problem now is actually adding the account. Gwibber’s UI stuff seems to be entirely separate from the core, and each service defines its own UI file. I had to create another py file to tell it which UI to use (I cheated and re-used an existing UI, otherwise I would have had to create that as well).

Gwibber is a good program that works well, I wouldn’t have chosen it as my test area if I didn’t like using it. The actual service modules follow a reasonable structure (although some are inconsistent, and there is no documented API). The problem is that everything is hardcoded into the client.
I’ve seen feature requests for other services in Gwibber, but at the moment it isn’t feasible to write support for those as some sort of plugin.

Maybe I’ve been hanging around Pidgin too long, but I think the concept of every service/protocol being a plugin that is loaded dynamically is a very good one; and something that would make Gwibber feel a lot more open to 3rd party development.


One thought on “Gwibber, or “Planning for Plugins”

  1. balingupjer says:

    hmm, doesn’t sound too promising…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s