So we came together in the afternoon and discussed some issues that we consider interesting enough to discuss.

The first one was IPC. We once again summarized the benefits of KDE switching to DBUS (among the lines of 'well maintained', 'support from toolkits and other desktops', 'distribution support already very high') and what bothers us with it ('C API', 'unsolved performance problems', 'unknown upgrade path').

So it was pretty clear, that we do should switch, but what we discussed in a pretty long and heated discussion was: how and on what level should we support applications accessing the KDE3 dcop interface. And so far we only found one use case that we consider important enough to support it: kpresenter/kdetv for KDE3 wants to disable the screensaver running within KDE4. All other dcop3<->dcop3 conversations have to be supported in a way as we do now when KDE applications started under twm. In that area KDE4 just has to make sure not to get in the way of KDE3 (e.g. different file names for communication sockets).

We all agreed, that scripting will be a major component of KDE4 and that we need to make sure it's as good as possible.

The discussion went a bit back and forth on the topics 'Do we support only one or several languages?' and 'If one, what language will that be?'. I was actually the strongest supporter of having a multi-language strategy, but in the end we left it to the developers there representing the actual kdebindings authors (Ian, Rich and Richard Dale) and they kind of agreed that one excellent binding is more than enough work. During the discussion on the numbers of languages to support it was already obvious that the majority of developers wants kjs/qsa (which are said to differ only in details so far) to be _that_ language.

Please note though that this whole discussion was just about scripting applicatins, neither about application development nor about heavy plugins. There is still something left to discuss, but we did a start.

Quit funny cause the feedback I got last year from majority of users and developers is, that they would like to have python or <put your fav interpreter her> as preferred language instead of ecma like scripts. Anyway, that's personal taste and shows one more time, that we maybe should provide at least an optional way to leave the decision up to the potential developer who decides that he likes to write some other binding and got frustrated by rewritting everything cause the existing scripting-solution is qsa/kjs only and couldn't be reused and, more worse, applications are bind to qsa/kjs only.

As already sayed above that doesn't mean to maintain a bunch of equivalent solutions for all existing interpreterlanguages like done today, rather then providing a plugin-framework where somebody is able to put his own scripting-binding in and use it as first class citizen even if not official supported by the KDE-project.

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).

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.

With more and more companies adopting Qt having a set of tools from KDE that only require Qt gives them a way to try out KDE's technology and hopefully then utilize our entire framework. This will give us more testers, contributors etc. The best example is a lot of the KDE widgets that you find in designer and a bunch of small helper classes in kdecore.

From a more fundimental level there is a heck of a lot of interdependencies in kdelibs that aren't needed at the moment. The thicker the graph the harder it is to debug. A lot of us wish to implement unit tests. Reducing the number of unnecessary dependencies will make this job easier. This also makes giving maintainership over to new developers a lot more easier. There has been a lot of talk about maintainers here at akademy also. Right now there seems to be only a few people who really understand and maintain kdelibs.

The concensus at the end of the meeting was not that we definitly were going to do this fyi, but to at least give it a shot and see how far we could get.