On Wed, February 16, 2011 1:44 am, Aaron J. Seigo wrote: > On Tuesday, February 15, 2011, Stephen Kelly wrote: >> http://steveire.com/kdelibs-modular.png >> >> * It's broad at the base - Qt developers can pick and choose what they >> want. There are less interdependencies - you can use the itemviews stuff >> without also pulling in KLocale KConfig etc. If you're happy with >> QSettings and QLocale (and Qt developers are happy with those), then you >> don't use them. * All the platformy stuff is at the top instead of at >> the bottom. >> * KDE applications know no difference. The platformy stuff is provided >> to them still. > > what's interesting is that we aren't as far from your "desired" diagram > already. your "what it looks like now to a qt developer" diagram is as > much a > matter of perspective as it is of the reality. yes, we have modularization > to > do (the item views, for instance, perhaps being a good example; kdeui has > several such things in it), but libkdecore is not such a big issue imho. > don't > want kconfig? don't use it. splitting it out to its own library is likely > to be more burdone that benefit.
There would be a major benefit from splitting KConfig etc out of kdecore: Qt developers could use the stripped down library confident in the knowledge that they could use any class in it without having to worry about whether they might accidentally introduce a dependence on platformy stuff. Having all the kdecore classes mixed together in a single library, as now, would mean that Qt developers have to check all the time which classes are "safe" to use and which aren't - and currently, that isn't even documented clearly. That puts up a big barrier to others using our library. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm