It seems that another week during GSoC has passed. This one was mostly GUI-related.

I’ve wanted to let people experiment with plug-in system ASAP. That is why I’ve created Plugins management window ([9762]), where they can (de)activate all detected plug-ins and read information about them.

I’ve committed another plug-in example (after Message Length Notifier) - Acronyms Expander ([9777]). Now, users have more elements to play with and I can test how Plugins window deals with multiple real-life elements.

Plugins management window

Current version of Plugins window, with it’s basic functionality, is a good base for further development. There are two tabs: ‘Installed’ and ‘Available’ (visible on screenshot).

First one shows plug-ins detected locally (installed). Here you can easily (de)activate them by toggling tick in table view on the left. This seems like an obvious way to do that

‘Uninstall’ and ‘Configure’ buttons are mocks. The first one will simply remove plug-in’s files locally. The second one will invoke plug-in configuration dialog.

‘Available’ tab will show plug-ins available on-line for download. Maybe using Capuchin.

Suggestions on this one are really appreciated, as this is what final user will mainly see.

Plugins window is accessible through Edit/Plugins menu item in Gajim’s roster (just below Preferences) - visible on screenshot.

GUI is built using Glade 3 with some parts, like gtk.TreeModel handling (used to store plug-ins list), in Python code. This approach is consistent with current Gajim code.

Acronyms Expander plugin

Message Length Notifier plug-in is useful but it’s not much to play with. So, I’ve implemented another plug-in for users to test - it’s a well-know (to many) Acronyms Expander.

It works “live”, so the substitution takes places while typing message. Below are hardcoded expansions of acronyms. This will be, of course, configurable, once I implement settings saving for plug-ins.

Currently the only invoker of expansion is ' ' (space).

To implement this plug-in for both, chat and group chat, windows I’ve added new GUI extension point. It’s called 'chat_control_base' and is situated in ChatControlBase class.

Acronyms Expander plug-in works well (without conflicts) with Message Length Notifier.

Unsolved cases and thoughts on upcoming challenges

Plug-in’s config

Main issue to solve now is configuration saving for plug-ins. We could pickle data to plain-text file, but it’s hard to read and modify - not human-readable, really. However, it’s fast and very general - plug-in could save anything.

Another approach would be to extend ConfigParser and implement cases of list (read from str) and maybe other types. Here, format is easy to read/modify outside Gajim (eg .using text editor). Unfortunately, AFAIK ConfigParser (as mentioned) does not support lists storage by default. So, we would have to use eval() function, and we want to avoid that (due to security reasons).

We could also use ConfigObj, but it would be another dependency - not sure if it’s worth that.

Apart from problem called ‘how’ there’s also a question of ‘where’. Probably, we’ll make separate config file for each plug-in. Sounds really reasonable, because one plug-in won’t mess up configuration file of another one.

PluginManager refactoring

I’ve, recently, realized that we might want to configure plug-in when it’s deactivated. In such case, I have to reorganize PluginManager a little bit.

Current version: keep class object for plug-in itself and instance object for activated plug-in.

Future version: keep instance object and call initialize(), destroy() methods when plug-in is activated/deactivated - these would have to implemented by each plug-in.

Automatic handlers (un)registration will be left untouched.

I could leave code as it is. But dealing with configuration at class object level would be a ‘programming abuse’ IMHO.

Extension points clean-up

GUI extension point clean-up is still unsolved. Extensions points called from objects that are not referenced by Gajim core anymore, should be removed. Currently, they are not deleted. Objects are still somewhere in memory, although not used, because they are on GUI extension points list in PluginManager).

Further tasks:

• start playing with network/xmpp events. Walk around code and think of events hierarchy and implementation.
• work on events generated by Gajim itself (like 'AccountConnected') (proposed by xbright). We would have to determine which events do we need and give plug-ins possibility to handle them. Signals are already generated for Gajim’s remote control - this looks like a good starting point.