Hi!

We had another heated discussion I would like to summarize. Somehow Danimo 
couldn't wait, but blogged 2 minutes after we finished the meeting, so there 
is few to say more than what you can read in 
http://www.kdedevelopers.org/node/1390

We were basically discussing a couple of things: 
kdebase in it's current form is too strictly bound to the UNIX desktop we 
developed so far. Many in the past raised the concern that you don't need 
kicker on Windows, but you still would like to have the ioslaves and the 
helpcenter on it - still both are bound together in one SVN module. So we 
decided to split kdebase into two subsets: those apps that are foundation for 
other applicatins and those apps that make up the KDE desktop. This wasn't 
really controversial.

The other aspect was much more controversial as it related to kdelibs. The 
idea presented was to split kdelibs into the parts that only rely on Qt each 
(most widgets, some of our kdecore parts) and those parts that are either 
grouped together to make up KDE's framework and the parts that rely on that 
KDE framework.

We had some ideas floating around and we still have to show if it's feasible 
and possible. But we decided to try _and_ what we decided that this 
development will happen in /trunk according to some guide lines we will set 
up just when the akademy is over. And that we will first do cleanups and 
movings around later.

And to make application development/porting in any way reasonable I branched 
kdelibs to /branches/work/kdelibs4_snapshot - you should use that one if 
you're not interested in developing kdelibs. Expect trunk/KDE/kdelibs to be 
broken at any random time (for now).

Greetings, Stephan

-- 
Mein Lebensmotto? 
Man muss auch mal 1+1 gerade sein lassen können.