Posts in category roadmap

On the plugin api stability of the 0.6.x (and the planned lack of that)

Recently the plugin/extension mechanism of great projects like py.test and flask have been an inspiration for minimalism and simplicity as well as for lack of painful labor.

The conclusion was quite a bummer - writing pida plugins is rather painful, full of seemingly unnecessary labor and not quite pythonic.

So we decided to try and take ideas from py.test and flask to reshape how plugins are written.

The target is clear - less labor, more fun, less dealing with dozens of dozens of classes.

Big news on the development front

As of yesterday i pushed about 150 changes to main.

The most important change is the removal of our dependency on kiwi, we worked hard to build the replacement named pygtkhelpers.

I also got around merging Bernhard Leiner's restructured-text plugin, which is a very good start providing a outliner and a validator for plain restructured-text as well as sphinx extensions.

Also we recognized a few new needs. Plugins now need proper custom per-project options in terms of api and ui (for example the sphinx base for the restructured-text one). Also we really want to run outliner and validator plugins on jit-ed python interpreters i.e. cpython+psyco/unladen swallow/pypy-c-jit. And of course, not to forget giving access to the java platform via jython.

The next step will be to decide if any of those should be done before the 0.6 release.

About UIs and the future of Pida

As Pida was started, there where two choices for the Toolkit in use. Gtk and Qt3 where available and gtk was the better choice at that time.

The years passed and so did the choices changed. The development on Gtk was rather slow compared to Qt and with the Qt4 a really major step was done which shifted the best choice to Qt.

Also looking at the available text widgets the choices are even more clear. GtkSourceView? got only very little improvement while with kate and other widgets are getting much improvement — while development on medit started stalling.

Now, while we are at it, why switch from one toolkit to another and not use the oportunity to make things right. So, the overall plan is to separate the gui elements from the logic first, and then start implementing a second gui in Qt.

With the XEmbed support in both toolkits, it as already possible to mix widgets with each other, but using it is rather ugly. For example can widget not be reparented without breaking the connection, but both run in the same main loop, which is a good thing.

As Qt does not provide such a cool widget as we use for the main window currently, this needs to be implemented first. Best would be in C++ so other projects could use it, too.

Investigation showed however, that it seems not to be impossible that a real mixing of widgets can be accomplished. We are already in the same mainloop on a X-Server at least. The best thing would be if we would find a way to use gtk widgets in a qt application.

This redesign is planned for the 0.7 release and 0.6 will become a long living gtk branch.