PyRoom Dev

Release planing

2010-03-12T13:14:00.001+01:00

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

2010-03-10T16:54:00.000+01:00

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 pyroom@florianheinle.de if you're interested!

Branch merged: alignment

2009-09-04T10:23:00.002+02:00

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

2009-08-27T21:39:00.003+02:00

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)

2009-08-27T15:10:00.003+02:00

Finally I found the time to start working on the long expected plugins branch.

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 Bazaar (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

2009-08-07T18:33:00.002+02:00

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 ~pyroom-team has served as a host for our mailing list, pyroom-team herecomesanat lists.launchpad.net, 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, pyroom-team herecomesanat lists.launchpad.net 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

2009-08-02T23:42:00.004+02:00

Now that the "config confusion" branch has been merged into trunk, 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.

Branch in the works: Config Confusion

2009-08-01T12:50:00.002+02:00

Changing PyRoom configuration at runtime is quite complicated, at the moment. While our configuration file is quite simple and easy to use, PyRoom at runtime makes use of at least three different ways of using configuration files. It works, but there's a lot of unnecessary passing around of configuration objects and not everything those contain is configuration. Some objects also contain runtime state data, such as PyRoom's absolute path, which it needs for theme loading, etc.

Our current configuration methods

Config file
Our configuration file, pyroom.conf is kept in an instance of ConfigParser and accessible to most modules (not all) and can be manipulated directly.

pyroom_conf
When starting PyRoom, this instance of preferences.PyroomConfig() is created and (some) entries from our configuration file are being set as attributes. This objects is passed around to other modules - but, again, not to all.

Preferences()
This is actually our GUI class for the preferences dialog. Some settings are held there, too. This is not actually passed around the programme at all, but it's used internally when changing preferences and applying the results.

Applying of configuration changes is somewhat complicated, too. Since most of our programme is GUI, most of the settings used apply instantly visible to the user, too. But there's different ways to this, too. Some functions that change configuration apply the settings by themselves and change the settings only in their own place. Sparsely, the same settings exist in different places, too and are not affected by the configuration change, which led to trouble in the past. Other functions, though, set configuration settings in the config file and run apply_theme(), which reads from configuration and pyroom_conf to apply the settings found there, ignoring aforementioned "invisible" settings in the process.

Saving of configuration is a different beast, too. Since it's always hard to tell where exactly settings and states reside, it's hard to gather those for persistent storage in the configuration or theme files.

What's about to change

I've created a new module globals, which keeps two dictionaries: state and config. The new globals module is available to all other modules and is intended as the only method of configuration and state keeping. config, of course, is backed by ConfigParser and can be changed from everywhere. Settings that change the GUI can be applied by GUI().apply_theme() then. state, however, keeps runtime data, such as if GNOME default fonts are available, paths to configuration, themes, etc and other things that don't need to be saved to the configuration file.

Branch in the works: Alignment

2009-08-01T11:34:00.004+02:00

I'm currently working on a branch that allows a different position for PyRoom's text entry box: At the top. It's not particularly complicated, but there's quite a difference in user experience involved.

We'll be offering the choice whether the textbox should be centred (as before and per default) or if it should appear at the top. In combination with setting textbox height to 50%, this allows text to fill up until the exact center of the screen. Any further line will stay at the center of the screen and, thus, potentially at the users' eye level. I'm sure there are users that would prefer this layout to the standard layout we offer with PyRoom 0.4.1

The branch itself is potentially ready for merge. What it still lacks, though, is testing. Implementing this feature required to switch to a different method of positioning our widgets, now we're using GTK Alignments instead of the somewhat hackish method we used before. However, I'm not sure if this method and our current implementation work nicely with multiple monitors. Unfortunately, I can't test it myself with my single laptop screen.

If you want to help testing, please checkout lp:~tiax/pyroom/alignment, run PyRoom from your new checkout and test the new positioning options. Should you encounter any problems, please post to Bug #363390 in Launchpad with a description (or patch..).

Our PyRoom Dev blog

2009-08-01T11:28:00.002+02:00

Welcome to our new PyRoom Dev Blog. Here is where we plan to post some articles about using and programming PyRoom. Don't expect political statements or daily blogging. What's not worth posting won't exactly show up here.