I'm pleased to announce the release of pida 0.6.2, over 100 changes accumulated and pida got faster.

changelog since 0.6

• switch to hgdistver
• switch back to setuptools
  • kill our build_doc command, build_sphinx works
• bump the required python version to 2.6
  • settings are now stored using stdlib json
  • puilder uses stdlib json
  • window state is now stored in json
• add execnet/py to the depends
  • port the nosetest plugin from dbus to execnet
• remove the last uses of the gtkforms module for pygtkhelpers
• fix up various transition-leftovers of the kiwi to pygtkhelpers switch
• ignore locales/translations for now
• switch to the most recent anyvc api
• use the real bpython-gtk since its availiable now
• beef up various core datatypes
  • remove document.unique_id
  • kill the buffer list markup helpers in document
  • move indexer functionality from project to a dedicated type

• kill the bugtracker service since we dont use launchpad any more
• bugfixes in the trac plugin (thanks Christopher)
• remove all parts of pida.utils.gthreads we have in pygtkhelpers
• remove the gtkhtml fallbacks of browseweb - webkit is the future
• removed the document encoding from the statusbar
• kill the PidaGladeView? alias
• better logging of service failures
• fix incorrect handling of missing libs on startup
• fix project removal (#411)
• revise the internal resource-finder

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.

After quite some struggle the last few years and many refactorings im proud to finally give the long overdue pida 0.6 series to the world.

The larges changes are

• new plugin system
• new core ui framework based on pygtkhelpers
• the first iteration of a language plugin system thats supposed to ease adding outlining/validation/completion for new languages
• a completely rewritten vim integration that leverages dbus for communication with vim and finally handles new unnamed files propperly

This release is also supposed to be the beginning of a workflow around more continious integration based workflow.

In the months to come we'd like to automate the release and testing process, so we can just lay back, and releasing of pida and the in-source tree plugins will be a process governed by automated testing and accumulation of change.

The long period of non-stable-releases has very been a pain foer users and the team.

We really don't want to repeat that.

Instead we begin to try end release every few changes that enhance the user experience.

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.

So, the Python standard library. Batteries Included. Pretty cool, huh? Yes, it's brilliant. I wouldn't be half the hack I was if not for those classic libraries like urllib.

But my expectations of Python have matured over the years, and these days I don't worry about dependencies, and just import whatever I can. Often I use a different library because it has features, performance, or I just prefer the API.

This is a list of libraries that I would never use the standard library equivalent.

Here is a list of libraries who's functionality should be in the standard library, but isn't

We are proud to announce the last beta of Pida 0.6. If no severe bugs will show up, Pida 0.6.0 will be release in the next two weeks. Please report bugs you find here.

It was a long time since beta2 and a lot of changes happened since then:

Core Highlights

• multiprocessing language plugins

Language plugins can now use a multiprocessing infrastructure which allows expensive operations to be done on other cpu cores. This increases the speed of plugins like python_lint and python dramatically and do not make the gui sluggish anymore.

• project file caches

Projects now have a filecache which allows fast queries to filenames and filetypes. The QuickOpen? plugin provides a gui for this, allowing the user to open files to which parts of the name, path or filetype are known

• very precise feature selection from LanguagePlugins?
• better filemonitor support
• new documentation (needs some gui work tho)
• lot of speedups
• lot of usability enhancements
• lots and lots of fixes

New Plugins

• RegexpToolkit? - helps you develop and analyze regular expressions
• QuickOpen? - fast file opener for project files
• WayPoint? - autogenerates waypoints when you surf and edit files and allows to jump back and forth

Known Issues

• Unstable on Ubuntu Jaunty

Add proposed package feeds and complain  here for their stubbornness

Fixed on trunk

• Wrong display of changed files
• Better documentation build and api docs
• Hard lockups when pida shows a dialog
• Maybe RuntimeErrors? at external plugins

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.

The website got some face-lifting recently. Changing to a trac only site allows us to easier manage the site. Also the site moved to a new server so things might be broken.

News about Pida