A Qt replacement for KGlobal::ref and deref

[David Jarvie]

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