The very short story is:

• Mosfet wanted Liquid to be part of kdelibs, but some thought this was not timing was not a good idea due to the 2.2 beta1 freeze. There were also some possible legal issues with Liquid.
• Furthermore, kdelibs is quite large already so Mosfet was asked to move some styles (especially the testing ones) to kdeartwork or kdenonbeta.

The situation did not resolve itself. Mosfet felt criticized and others felt that he should give in a bit because for the benefit of the masses (the KDE users).

Because some of the code Mosfet contributed to KDE are critical parts for a release such as his KWin and Widget styles, the KDE project has forked this code while Mosfet will still develop his own versions and release them separately.

Neil Stevens wrote: I just found out, to my surprise, that I volunteered to do the System++ style. That's fine by me, I'll take it and add to it what it needs, but it shows there's a little confusion going on. Do we know who's taking over for Mosfet for maintenance of the various things of his that are remaining in cvs? Perhaps it's a good idea if we just spell out here who's doing what, so that we don't get any nasty surprises later on.

An answer was provided by Karol Szwed:

While the list of new maintainers is not complete yet and subject to change, it looks like this is still a happy end as far as the KDE users are concerned. Upcoming KDE versions will continue to include their favorite styles and Mosfet can release the fruits of his creative skills, without having to face restrictions that come with being part of a larger whole.

KDE2 has been racing ahead on just about every front. However, not every application or library gets the same amount of time paid to it. This is often because the people maintaining that part of KDE2 have real life responsibilities that preclude them from spending as much time as they would like to hacking on their pet projects. One area that has especially suffered from this is the KDE2 PIM package. KOrganizer has been moving ahead as has the KPilot palm pilot sync program. However, the KDE2 PIM developers felt that there wasn't enough forward movement happening and that the kdepim module was simply not keeping pace with the rest of KDE2 development. To address this, Mike Pilone wrote a "KDE PIM Roadmap (Call To Action)" as follows:

This email inspired a large amount of positive discussion from the developers involved with the various parts of KDE PIM, along with some new faces. Storage mechanisms, address book architectures, data sharing, XML formats, conduits for handhelds and more were discussed in great detail. If even a fraction of what was being discussed sees the light of day, KDE2 users should end up with a brand new PIM architecture that will be very flexible and powerful. Of course, reporting on things that haven't occurred yet isn't the best policy. So as developments unfold and proposals become reality in the KDE2 PIM world KC KDE will strive to give comprehensive coverage of the events.

Aurélien Gateau wrote in: I'm writting a KDE application which could really benefit using threads. I wanted to use Qt-mt, but I read that it was not possible since KDE currently doesn't link against Qt-mt. and asked I would like to now what is the current politic regarding threads in KDE applications ?

Various people responded, some explaining how to use threads in an application and others advocating that one should not want that in the first place. Cristian Tibirna explained why KDE does not use threads at the moment and how Konqueror can still respond to user events while also downloading data from the network, without threads: KDE uses a technology called KIO (KDE's input/output technology) to accomplish this. These use the "many processes" as opposed to "one process/many threads" approach. There is a continuous religious war about processes vs. threads efficiency and performance but for now we don't care about this. Qt's support for multithreading is very young and (perhaps) still fragile. We will wait for it to mature (heard Qt-3 does it) and then we will start using threads more than currently, as Waldo says.

Waldo Bastian responded:

A general discussion on multithreading continued for a while and Aurélien received more help and hints to accomplish his task without using Qt-mt.

Most programmers know the feeling of having been around a project too long: the problem space doesn't feel sexy anymore; there aren't any new features that you really, really, really want to add; staring at the same code for what seems a very long time is getting really stale. The primary coder of the applet that comes with its own integrated desktop, KNewsticker is no exception to the rule. Frerich Raabe posted to the list looking to pass the torch on saying:

Of course, this is exactly the type of opportunity that is perfect for someone looking to get a start in KDE development. A few people replied saying they would love to spend their limited free time maintaining and perhaps even extending KNewsTicker further. All the KNewsTicker users await their efforts and the ongoing evolution of this very popular applet.

GCC3 was released this week. For those writing programs in C++ this was a much anticipated release as it promises better standards compliance, better results, and a stable ABI among other things. The day GCC3 was announced Mathieu Chouinard asked, Does anybody have compiled KDE 2.2alpha2 with GCC 3.0?

Nils Holland reported his limited success with GCC3 saying, I just put GCC 3 on my test machine and aRts really won't work properly. Most other parts of KDE do (more or less). If it comes to compilation times - well, I was away most of the time it compiled, so I cannot say much yet ;-) However, I won't put GCC 3 on my workstation until it has shown me that it is able to compile the whole KDE stuff. Seems that we'll have to wait for the next maintenence release of GCC 3 (which will come soon, according to the announcement I got from the gcc-announce list), which will *hopefully* deal with the virtual inheritance bug (and probably some other known bugs as well). Several others reported the same problem when compiling aRts with GCC3. Workarounds for the new compiler allowed it to build the code, but the resulting aRtsd would segfault on running.

Trill Krech also reported that compile time is considerably slower with the new GCC, while Christophe Prud'homme gave a good run down of some of the issues surrounding using the new, more standards compliant compiler with older code. The GCC team is apparently putting out a maintenance release of GCC3 in short order, so hopefully KDE2 will soon be able to take advantage of the the hard work the compiler people have been putting into GCC in the near future.

Milo Hyson announced the revival of the CyberLife Labs KDE CVS server saying:

David Faure inquired if it would be possible to make this an anoncvs server as well as a cvsup machine. Milo complied and in short order there was both anoncvs and cvsup services available. It's great to see this resource back online and available for general use. Thanks go to Milo and CyberLife Labs for sponsoring this new server.