Friday, April 30, 2010

Plugin Authors: Save Your Users' Sanity!

OK, maybe I'm being a bit sensationalist there, but it's my blog, so I'm allowed! Anyway, on to the subject matter.

Recently we've seen a few users in #pidgin (and I've received some emails too) with some strange issues that result from plugins doing things they really shouldn't but can anyway. I'm going to run down a small punch list of items for you, as plugin authors, to do to prevent your users having hard-to-diagnose issues.
  • Never use printf() in a plugin. This causes terminal disruption for Finch users and is a bad idea in general. It will probably behave unpredictably on Windows and/or in other UI's too. We provide a debugging API to avoid this kind of stuff. Instead of printf(), use purple_debug_info() or purple_debug_misc(). You can see the debug output (even during initial startup) if you run 'pidgin -d', even on Windows and even if your Pidgin is built without '--enable-debug'. For Finch, you can do 'finch -d 2> finch_debug.txt' to get your debug info.
  • Don't lie about UI requirements. If you use GTK+, you're a Pidgin plugin, not a "core" (or libpurple) plugin. If you use GNT (or if you're really brave and use ncurses directly), you're a Finch plugin. There are plenty of examples in the Pidgin and Purple Plugin Pack source trees that show you how to properly declare your UI dependency. The UI requirement is designed specifically so that plugins requiring a specific UI can't be loaded by, and thus cause problems for, other UI's. Sure, it's possible to make a UI-agnostic plugin that requires GTK+, but I guarantee it will cause at least one or two Finch users unnecessary problems.
  • Install your binaries to the correct place. If you're installing a Pidgin plugin, install to $prefix/lib/pidgin, not $prefix/lib/purple-2. If you're installing a Finch plugin, install to $prefix/lib/finch. This will prevent other UI's from needlessly trying to probe your plugin and is just general courtesy. (Note that this particular item doesn't apply to plugins for Pidgin on Windows at the moment, but may be important later.)
  • If your plugin is a protocol plugin, you absolutely are not allowed to touch UI-specific code at all. That means no GTK+, no GNT, no XUL, etc. If you need UI elements, use the request API libpurple provides. If the request API doesn't cut it, there are other approaches you can take, such as having two plugins, one of which does the actual protocol work and the other providing the UI. A better approach, though, is helping us identify where the request API is lacking so we can improve it. We know our API's aren't perfect, so when someone can show us a concrete reason why we're deficient, we will try to fix that deficiency.
Please check your plugins for these problems and help your users have a more pleasant experience with your plugins!

Tuesday, April 27, 2010

Time flies...

It feels like it's been forever since I stepped up on the soapbox to say something. This time it's just a relatively short update.

As is very commonly known, Pidgin was accepted as a mentoring organization for the Google Summer of Code again this year. This year, Google has given us the privilege of mentoring four students. While less than we hoped for (we'd wanted five), we certainly can't complain about the projects we were able to accept.

First up is an MSN project manned by Jorge Villasenor Salinas, who some may recognize as having helped implement custom emoticon support for Pidgin 2.5.0. His project is to rewrite the SLP layer of the MSN plugin, simplify the other parts of the plugin, and overall make the plugin much easier to maintain and extend. I'm sure he'll be trying to squeeze some new features into his project if time allows.

Next up is one of my personal favorite projects for this year. Gilles Bedel will be working on detachable sessions. This is something a number of us have wanted for a long time, but just haven't quite gotten around to making it happen. The idea here is that we can have a daemon (service for the Windows-inclined among us) running in the background and connect to it with Pidgin or Finch at will. I feel that this is perhaps the most ambitious project this year, but the benefits it could reap are worth it.

Adam Fowler is going to rewrite the log viewer in Pidgin. This particular project will likely be the only project that visibly changes Pidgin this year. We've received a lot of complaints and suggestions over the years focusing on our log viewer. We know it's deficient in a lot of ways, and that's what Adam's project aims to resolve. I'm confident we'll get a lot of positive feedback about this project once it's complete.

And last, but not least, is Ivan Komarov's ICQ project. Ivan's aim is to beat our ICQ implementation into shape. As most of our non-US ICQ users can confirm, our interaction with the service could use some improvements. While Ivan has proposed a nice wide range of things to fix, even just a few of them being completed would make a huge difference for our international users.

So, from all of us developers, and we hope from our users too, good luck to our students!