There has been a lot of talk. Here are a few points: 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 definettly were going to do this fyi, but to at least give it a shot and see how far we could get. Hopfully I covered the main points, anyone else feel free to point out anything I missed. -Benjamin Meyer On 9/1/05, Olivier Goffart wrote: > Le Mercredi 31 Août 2005 13:22, Olivier Goffart a écrit : > > Le Mercredi 31 Août 2005 11:39, Stephan Kulow a écrit : > > > 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. > > > > I just have a question. > > Why making this ? What are the interest of that split, and motivation ? > > This is just a question to let me understand. > > May i have an answer please ? > > > I am not at akademy, so i am not aware of all discussions. > I guess this has been debated a lot. So what are the reason of this change > ? > This is just for my personal interest. please let me know :-) > > thanks. > >