It's getting colder. KDE CVS now is in deep freeze for 3.4 beta 2. All messages are frozen so that translators can start to strive for the perfect translation in 79 languages. The day before the freeze saw some frantic activity of people to complete their last-minute feature or to sneak in the messages required for fixing certain bugs. On the kdepim front we got a new Kontact welcome screen and were able to break compilation because of our wicked intra-module dependencies.
The prospect on KDE 3.4 is great. I'm using KDE HEAD on my production machine at work since a couple of weeks now and I don't want to go back anymore. KMail, as the program I most heavily use, has significantly improved once again. Some of the credits for that go to the OpenUsability people who have helped a lot with improving the usability of the KDE PIM applications. That's the pragmatic approach to usability and it fits very well to the way things are done in KDE. We need more of that!
Another aspect of KDE PIM which saw lots of progress during the last couple of months is groupware server support. Kontact now is the client with the broadest range of support for free software groupware servers like Kolab, eGroupware, Open-XChange as well as proprietary ones like Novell GroupWise or Microsoft Exchange. Especially interesting is the support for OpenGroupware.org, because that's not only support for a great free software groupware server, but also the first prototype implementation of an upcoming groupware protocol standard.
Essentially to the progress of KDE PIM 3.4 were the couple of personal meetings and hacking sessions we had. These really boosted the development. There was for example the big aKademy event, a ferocious hacking session at Magdeburg and the now traditional KDE PIM event at Osnabrück. These events were lots of fun and an incredibly productive environment for writing code and improving KDE. It always astonishes me what is possible when you get the right people at the right time at the right place. The sky is the limit (if there is a limit at all) :-).
And I wonder, will there be a KDE 3.5? I guess, as QT 4 isn't there yet, it'd be cool if the application writers could continue writing, while the people from KDE-base and KDE-libs could start porting to QT4 - so after KDE 3.5, the app writers already have an almost-complete kdelibs4 and kdebase4, so they can port easilly, and KDE-base will be very stable when KDE 4 is ready...
or am I just plain stupid :D
I don't think we should separate KDE 4 development in a library and an application development phase. This has to go in parallel. Only when the application actually use the KDE 4 libraries it will be clear how the API has to look like. This can't be done theoretically.
But if there will be a KDE 3.5 is another question. Many people seem to want this.
i like this idea
i don't think Qt is ready for us to start porting, and i don't think users can wait until 4.0 is ready. Personally I love the idea of examing the current KDE to see what needs to stay in KDE libs and what is missing. There are some classes in kdelibs that are currently not used at all that are just throwbacks from times when Qt didn't support features we want.