Release planing

Hello everyone,

after it's been a little quiet around PyRoom lately, I'm now planning on two releases quite soon:

• a release in our stable 0.4 branch that fixes some bugs, including the one that keeps PyRoom from starting under certain conditions (locales..)
• an experimental release in the yet-to-create 0.5 branch (from trunk) that will feature the not-yet-rock-solid plugin architecture. 

Users will be advised to stick with 0.4 for some time. Maybe I'll change our versioning to something like the old scheme used in Linux, where odd numbers represent in-development versions. But that's just random thoughts for now.

Still, we'll have to find a solution for the translations issue in Launchpad. I'm not quite comfortable with shipping untranslated versions of PyRoom, especially given the tremendous and awesome effort put in by so many of you that translated PyRoom in many languages, but I'd rather not deal with the situation in Launchpad and mess up, either. So, again, if any of you feels comfortable handling translations in Launchpad, please contact me here or via mail so we can work this out.

Help wanted: Translations management

As many of you know, PyRoom has become more or less a one man job.

While I still have time on my hands to handle coding tasks, there is still one thing I cannot seem to get my head around properly. It's quite an important task that should not be handled lightly by someone (me).

Therefore, I'm looking for help handling our translations in launchpad. At the moment, organization of our translations is not optimal, we have quite a few branches and are only maintaining one of those. Automatic import/export to a launchpad branch could be set up, etc.

All in all, I'm looking for someone experienced with launchpad, specifically translations to help out. Please comment here or write to if you're interested!

Branch merged: alignment

While we're still working on the plugins branch and, at the moment, are building the GUI necessary for managing the plugins, we have finally been able to merge the alignment branch. The thing is, we just couldn't find anyone to test it on a multi screen setup.

I've attached a screenshot to my post, showing how text input can be aligned to the top now.

Some plugin ideas

Just a small collection of small but useful plugins that don't exist yet, but may soon:

• GIO for network access to files. Not in core because of the GIO dependency


• export markdown/textile/rest/creole to html


• some sort of timer/a clock


• speed dial/savegame like display of recently used documents instead of file chooser


• spell checking


• syntax highlighting (there! I said it!) for LaTeX/markdown/textile/creole


• publishing prose to publishing platforms such as LiveJournal, a blog, whatever


• versioning. Not reinventing the wheel here, think "vcs integration"


• YouTube and twitter widgets. Just kidding.

Oh, just one thing: syntax highlighting for LaTeX will replace our gtk.TextView() with an instance of gtksourceview (of gedit fame), which means it will be able to highlight most programming languages, too. Still, PyRoom isn't intended to be a programmer's editor. Please don't use it as one or I'll come after you with a knife.

Branch in the works: Plugins (part II)

Finally I found the time to start working on .

The plugin architecture I've decided to use is quite simple, let me describe it briefly:

A plugin is implemented as a subclass of PyRoom.plugin_manager.Plugin() and needs to have certain attributes: [capabilities], a list of capabilities the plugin provides and, for each capability, a do_capability() method. Additionally, a plugin may override the builtin activate() method, which will be called when the plugin is loaded.

Plugins are stored in python modules that may contain multiple plugins. Modules containing plugins can be activated and deactivated, activating all plugins inside in the process. This is by design to allow bundling of plugins with features that depend on each other.

What's already been done

Currently, I've implemented a number of different hooks that call plugins by their capabilities in appropriate places of the code:

• on startup


• when the GUI has been set up completely


• when creating keybindings


• when buffer information is shown (i.e. Ctrl+I)


• before saving a file. It's possible to disable the standard file saving method here.


• after having saved a file

Plugins have access to both global objects state (including state['GUI'] and state['edit_instance']) and config.

There's quite a few opportunities for monkeypatching the GUI via plugins. This makes the system somewhat rough around the edges, but at the same time provides a lot of freedom to change things. Still, exceptions thrown in plugins, (hopefully) won't crash PyRoom, basic error handling displays a dialog box about the crashed plugin to the user and will offer to disable the plugin from now on.

What still needs to be done

I have a few plans for the plugin system.

First, we'll need some sort of a GUI for activating and deactivating plugins without restarting PyRoom.

Second, which is more interesting, would be a central repository for plugins users can browse and plugin developers can submit to. Updates included. The easiest way to do it would be to use (because we use it for PyRoom development, substitute any other VCS, though..) for the plugins directory. File system permissions aren't a problem here, we'll just put it into the user's XDG home data directory. Still, we most likely won't be adding a dependency to a VCS to our simple text editor. We'll most certainly will be rolling our own solution here, although the VCS approach seems inviting.

Long story short, we'll have to integrate some sort of installation and update mechanism to the gui we're already planing.

PyRoom discussions

Good news, everyone! We have sorted out some things about the mailing list.

Sometimes recently, when I came online in the morning, I checked #pyroom logfiles, I saw users asked questions about PyRoom and/or PyRoom development, but they received no response. It appears that most of those who come and ask questions come from the US or other countries outside Europe, where our developer base comes from. Without an active and big idler base, time zone differences can be quite a killer for communication.

To somehow mitigate the issue, we've improved on our mailing list situation. PyRoom is driven by quite a few different teams on launchpad, to manage permissions etc. Until now, the team has served as a host for our mailing list, , but whas on a moderated basis. While that's not such a bad idea for "teams" at all, mailing list access is coupled to that.

From now on, though, and its mailing list are free for all and should be a little more convenient to use than our IRC channel. While our user and developer base remains small, we'll be discussing both development and support issues there.

Branch in the works: Plugins - and why we want them

, the way is free to work on a more exciting branch: The long awaited plugin System.

Now, as long as we've been planing to build a plugin system (and that has been one of our plans for months), we've always been asked the legitimate question, why a text editor without distractions needs a plugin system.

The prospect of managing a whole lot of things before just starting to write is indeed not quite what one might be looking for in our project. But, fear not, we have taken this into consideration.

First thing is, we still want to provide a solid core for PyRoom that works out of the box, no configuration needed. That has been and always will be one of our goals. Now that this concern is out of the way, let's head on to some more lengthy reasoning about why we think a plugin system actually helps us keep out feature creep of PyRoom.

In the past, we've received a lot of feature requests. Some of those have been incorporated into PyRoom, but others had to be declined. Among those, most were actually good suggestions that would really have improved the overall PyRoom experience - but not for everyone. Some feature requests were quite legitimate for a subset of our users but would have bloated the programme for anyone else. As an example, a long standing and very plausible feature request is syntax highlighting. This would be quite an overkill feature for most writers, but certainly not for those editing LaTeX files.

By providing a plugin interface, we plan to allow some kind of compromise between keeping the core of PyRoom lean and productive, while allowing selective addition of features by installing plugins. This actively helps us keep features out of PyRoom that not everyone might be interested in dealing with.