As some of you know, I’m playing a guitar, and recently a feadog. This of course means that one of the things I’m gathering are chords, tabulatures and tunes.

For last few years I missed a songbook of my own that would cover everything I like to play, something that I could just take with me on a tent camp. Of course I have many songbooks but none of them is enough so I usually have to take all of them while I use only four or five chords from the whole book :/ Another problem is with my own chords.

I started trying to create my own songbook while ago, using either Koffice or OpenOffice. The issue is – I’m a nerd. I don’t want to simply write a text and put capital letter D, A and G somewhere around. I want a markup. I want symantic. I want to be able to extract any piece of data later. I want to be able to change the translation of the song while keeping chords in place. I want to be able to put tunes or tabulatures anywhere around without a problem and connect them with words of the song.

There is ChordMLMusicXML, MML, but none of them serves what I need. (with ChordML being pretty near I think).

So, I’m going to try to figure out if ChordML could be modified to suite my needs or not. In either case I’d like to spend some time on this project and have some nice XML files with my songs soon, with XSL sheets to export it to ODF or XHTML.

How nerdy it is? 🙂


KDE4 subsystem freeze

By the way, I almost forgot to blog about KDE4 progress!

So, according to the new roadmap, KDE4.0 Subsystem Freeze already happened and it means, that from now on, the major focus of kde community should start shifting from kdelibs to kdebase/kdenetwork/kdemultimedia etc.

In the last months, there was an enormous amount of changes in kdelibs. Every single day, when I did svn up on kdelibs, it exceeded my terminal backlog!!! But the results on the front-end were minimal. If anyone tested kde trunk, you could see a few changes here and there, minor updates to a few UI’s and a few major things like dolphin, oxygen icons, okular or amarok 2. But you couldn’t see the result of plasma, phonon, decibel, solid, strigi, nepomuk or sonnet because it happened on the kdelibs level.

People expect changes to happen vertically – when the project changes sound lib, we should see fancy new sound utils at the very same time. But such approach would be very bad for devs. It would require them to split their work focus and it would mean that they’d have to rework the front-end after each major change in kdelibs. It’s much more efficient to rework low-level libs and then rework front-end basing on the new libs. Easy?

So please, do not yell on KDE4 if you’re not into kdelibs, front-end work will start very soon 🙂

btw. same happens in Mozilla world. Launch Firefox trunk – it looks exactly like Fx 2. Front-end changes will start appearing once back-end will cool down/freeze.


Mozilla 2 ignited!

I think we can use Brendan’s post from, as a real beginning of Mozilla 2 era. Of course we had design specs earlier, and Brendan spent quite a lot of time on JS2, but this post is a bridge between concepts, and a list of actions that we’re going to take.

Also, we have a new Mozilla 2 wiki page, that contains a very experimental, unofficial and NOT_FOR_PRESS, timeline. It predicts that we’ll ship Firefox 4 around Q1 2009, and that might be interesting for you all 🙂

Mozilla 2 is a huge project that will require a lot of effort from all our volunteers, and this project should give us, in result, a stable platform for another 7 years or so (Mozilla 1 was released in 2002).

I could name only one such major rework in the open source model yet and it’s KDE4 project. Both are very challenging, huge upgrades, very ambitious and if successful, will prove that open community driven model of development is flexible enough to be capable to handle huge, user oriented products in a very long term in changing environment.

So, instead of crossing your fingers, Mozilla would appreciate if you could put them on your keyboard and join us in this crusade 🙂