A Qt replacement for KGlobal::ref and deref

[Stephen Kelly]

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.

If it were that easy, Gregory wouldn't have forked. He's not the only one 
either. The MeeGo use of KCal includes forked KDE stuff:

http://conference2010.meego.com/session/organise-your-life-calendar-meego
http://meego.gitorious.org/meego-middleware/meego-kcalcore

Yes, part of the reason is about communicating, part of it is about 
consequences of using kdecore. There's daemons to be run etc, you're pulling 
in stuff which you know you don't want to use, like the locale and config 
stuff and a k plugin system, and you don't know why they exist.

> 
> there's also libraries like solid, phonon, attica, qca(, akonadi?) which
> are already in that "tier 1" line. even so, we don't communicate that well
> at all and our build system layout and the "social contracts" we have with
> packagers don't help at all.

Another thing to remember is that Qt developers wouldn't necessarily use 
packages from debian or whatever, especially if they're putting together an 
application or software which they distribute or bundle by their own means. 
Splitting in packages might be useful from the communication or 
discoverability angle (Oh! apt-cache tells me libsolid only depends on Qt. 
I'll use that!), I don't think it helps a lot technically in the appeal to 
the Qt community.

> 
> so, good news is that we're closer than one might think from the outside
> looking in. bad news is we still have quite a bit of work, particularly in
> kdeui, kio and our build/packaging/communication targets.
> 

Yes, it's not as bad as it might look like I'm claiming :), there's a lot of 
useful changes within reach, or currently just out of reach. I think if no 
kde library needed to depend on kglobal or any other internal parts of kde 
which creates interdependencies by nature that would be a huge win.

Why does KGlobal::locale() exist, for example? Why isn't that a static 
method on KLocale? That would mean locale-needing libraries can use that 
without depending on KConfig.

More food for thought.