More than a week passed since GSoC kick-off meeting took place. So it’s time to summarize a little bit.

For those that don’t like reading longer posts - in short: Gajim (de)activates plug-ins while running and first plug-in works pretty nice. Detailed report follows.

At the beginning…

…there was creation of new branch in Gajim’s Subversion repository, dedicated to plug-in system ([9703]). Thanks to this, I’m independent from trunk and what is going on there (aka I-won’t-break-trunk). Main problem here is that merging branches in Subversion might be pretty painful.

But still (nevertheless I’ve been warned by Kev), I’ve decided to use it instead of DVCS like Git or Mercurial. Mostly because of two things:

• plug-in system won’t make many changes to current Gajim core (so it might not be so hard to merge branches at the end) and Subversion is already there, working.
• I bought Wing IDE Professional about two weeks ago and I wanted to have support for VCS within IDE. Unfortunately, WingIDE supports only SVN, CVS na Perforce.

Wing IDE - Python helper for project new-comers

After some time, it occurred that the second statement (in the list above) is not necessarily a good argument. This is because, SVN support Wing IDE is not the best I’ve ever seen. To be honest - it’s pretty basic compared to Netbeans or Eclipse. I ended up using console to interact with SVN - it’s more handy.

However, Wing IDE is a great tool to explore Python code. It’s source code analysis is probably the best one available on the market. Whole IDE is pretty fast, has nice debugging facility and integration with PyLint. Automatic indentation checks are pretty handy to keep code consistent with Gajim’s core. In fact, there’s a small clean-up commit in trunk that is the effect of using this feature in Wing IDE: [9704]

Some things that WingIDE badly lacks (apart from DVCS support):

• movable tabs
• all-at-once highlighting when searching
• show-all-usages of function/class/variable (there’s only ‘go to definition’). Someone even posted feature request for this today on wingide-users mailing list.

So much for the IDE I use during GSoC. Going back to project itself.

Few words about trials of Getting Things Done

First of all, I’ve decided to use tracer bullets approach for my GSoC project. I think three things are important for me in this method:

• I meet problems that I wouldn’t imagine (in finite time), keeping all the ideas and code only in my gray matter. There are lots of things that you can miss or forget. However, Paper-And-Pencil(tm) application might slightly reduce this problem.
• I can get feedback from people early, because some code begins to work pretty fast. Of course it’s not perfect. Many elements need polishing or modifications, but still - the code works.
• Unfortunately I have other projects that I have to work on in parallel, so thinking about project only and no coding would probably end-up in freaking out (being overwhelmed by amount of work to be done)

This way, I move forward. Sometimes making bigger steps, sometime smaller, but permanently towards building plug-in system for Gajim.

What I’ve noticed, is that using this approach I always know what to do next. Not only at general level of project by also at code level.

I’m lucky because I write my GSoC project in Python which simply makes prototyping fun.

I admit I feel inspired by “Getting Things Done” that I got from XSF (stpeter, Kev: Thanks, once again). I especially liked paragraphs about procrastination

Initial commits and testing

After creating own branch and doing some coding I’ve commited a few files ([9737]). Later, some improvements were made ([9745], [9754]). Resulting code has:

• new package called plugins where I keep code related to plug-ins system
• PluginManager class where all plug-in management related actions are placed
• GajimPlugin class that is supposed to be the base of of all plug-ins. All subclasses of it are treated as plug-ins.
• helpers module that includes: Singleton class, customized logger and functions decorator that logs when function is enter and when left
• test_pluginmanager.py file that holds tests (or I should say: one test) of PluginManager class
• additional variable common.gajim.PLUGINS_DIRS where directories to seek plugins are hardcoded. Maybe later we’ll decide to move it to config file.
• first call of GUI extension point in ChatControl class
• first plugin that makes use of this extension point was implemented. It’s called Length Notifier. I mentioned it in previous post when in was in a form of monkey patch. It highlights message entry field when given length of text in exceeded. Pretty useful with microblogging bots, eg. Twitter.

Notes on PluginManager: directories are scanned for ‘*.py’ files in which they search for GajimPlugin subclasses; plugins themvelves are held as class objects in list (maybe I’ll change it to set), while activated plugins are held as instance objects in separate (also) list;

Notes on Singleton: this implementation calls __init__ only once in contradiction to version that is in “Python Cookbook”; I’ve been warned by Kev that singletons might be deadly. So I’ll have to decide , whether I really want (need?) only one instance of PluginManager, before releasing plug-in system to the World.

Notes on LengthNotifierPlugin: some data (i.e. handler IDs) needs to be stored per object, this is done by assigning dictonary to object as new attribute; this is a simple solution and Python allows such approach, so why don’t do it this way? Plug-in developer, of course, can modify object in any way he wants. One of such modifications is saving data to object.

Notes on testing: I’ve copied some initial code from bct’s tests on sessions. Unfortunately, we have to make some dummy objects, to get tests run. Without that there are exception like NameError or ImportError - it’s mostly related to configuration. This init-hacking part will be probably extracted to separate module¹ as it seems, that all tests will need it.

API docs and Epydoc

Probably I could write even more descriptions of code here, but a better solution is to keep all this information closer to code - yes, in code documentation

I started discussion about documentation standards last week, because I wanted to create docs in format consistent with the rest of Gajim’s code.

The result of discussion can be seen here: http://gajim.org/apidocs/ .

The decision was made to use reStructuredText syntax for documenting and Epydoc for API docs generation. It was chosen because it’s Python dedicated and permanently under development with new features in each release.

The use of reStructeredText seems to be a reasonable one, because, as mentioned by Torsten Bronger, there’s a PEP on using it in Python code documentation (this makes it, more less, a standard). Apart from that, reST syntax in Epydoc has consolidated lists which makes docstrings more readable, IMHO.

Targets for (not so) near future

Things that I plan to do next:

• short-term:
  • make erasing GUI extension points possible (currently: references stay on list in PluginManager even if Gajim doesn’t have interest in them anymore)
  • decide on how to store plug-ins config - first shot here would be to generate API for plug-in developers, implement some local saving/loading with pickle and later integrate with current mechanism that Gajim use for configuration. All of this is because present Config class is pretty restrictive. I’ve already had discussion about it with Jim++.
• long(er)-term:
  • GUI for plug-ins management - to get more feedback from users. If there’s GUI more people may feel encouraged to test the branch.
  • scan for packages and zipped code, not only for module files
  • add GUI extension point for roster and for one of context menus in it - this will cover most of the GUI that potential plug-in developers are interested in
  • discuss about handling events, filtering them - generally, the network-related part of GSoC

To see more TODO and BUGS info checkout docstrings in plugin-system branch.

Ending note: I don’t know whether such (more less) detailed reports make sense. It took me some time to write it. I’ve spotted that, especially, creating links consumed a lot of time. Maybe I’ll have to look for abbreviations plug-in for Wordpress. Another solution would be to put only summary here and point to detailed descriptions in docstrings or changesets.

Any suggestions appreciated - have you found all this info useful?