As Gary announced in his last post, I'm one of the students accepted for Google's Summer of Code program. During the summer I'm going to work on better label placement capabilities. Since the application form is not publicly available, I put here the interesting part that briefly describes the main areas I'm going to address. If you have any suggestions, please leave me a note in the comments.

It's been quite a long time since my last blog post. In the meantime I was quite busy with getting my bachelor thesis ready. It's about creation of a simple navigation system for vehicles. In case you'd be interested you can take a look at the thesis [PDF], but it's quite tough reading as it's written completely in Slovak language :-)

But the more interesting thing is that second part of the work was implementation of a routing/navigation system and I've chosen Quantum GIS and Python to do it. This implementation is now available online, it's called Quantum Navigator (guess why!) and licensed under the terms of GNU GPL.

Some time ago I've started with porting Tim's tutorials posted in the blog to Python. The main reason
of doing it was to check that bindings work correctly. I thought that some people might be interested in using them so you can download them.

Some of the changes in refactoring branch since my latest blog entry are worth mentioning. Python support is getting more stable. Support for plugins written in python has been added. Interface for vector providers gets improved. And yesterday QGIS libraries got spatial indexing using R-trees.

Few days ago I've seen in PyQt4 ChangeLog that there has been added support for Qt4.2 classes recently. I couldn't wait for official release, downloaded the latest snapshot to see if we can move on with Python bindings for QGIS. Sure we can!

Recently I have played a bit with the Quantum GIS build system. Currently we use classical approach by using autotools: autoconf + automake + libtool. This build system is used in many programs with success. Originally it was designed to solve portability problems when using different flavours UNIX systems. With time it became very popular as it takes much of hard work off the developers.

However Autotools system has also issues. It's not easy for average developer to use or even create autoconf macros because they use M4 macro processor spiced with shell programming. These tools are quite complex and therefore a lot of tasks in maintenance of a project's build system's is nightmare for many developers. And finally it doesn't support Windows platform natively since it doesn't provide unix-like shell with some common tools like sed.

It's time to look for a better and more modern alternative. CMake is one such alternative, in recent time quite famous because KDE developers decided to switch to it for upcoming KDE4. Let's take a look on it.

This summer was for me exciting as it was the first time I've managed to cross the borders of european continent and visit Peru for 2 months. Together with my friend we have visited many places, spoken with many people, done much trekking in Andes, eaten many Peruvian specialities and had much fun.