Categories
tech

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.