A Qt replacement for KGlobal::ref and deref

[Stephen Kelly]

Aaron J. Seigo wrote:

> On Wednesday, February 9, 2011, Stephen Kelly wrote:
>> http://techbase.kde.org/Projects/KDELibsModifications
> 
> good to see people thinking about these things. however:
> 
> this page belongs on commuity.kde.org. it's already linked from here:
> 
> http://community.kde.org/KDE_Core
> 
> and it should be moved over.
> 

Done.

> one thing that jumps out at me is the use of terms like "library" when
> really it means "classes". there's an implicit assumption on that page
> that libraries like kdecore will be split up into N different libraries.

That's what I was suggesting on the page, yes. I don't know about how much 
granularity makes sense there, but that is what I was suggesting.

> while i think there's an easier case to be made for some of other
> libraries such as kdeui (which is a huge collection of rather different
> kinds of things) and kio (which quite evidently mixes framework and
> platform concepts into one library), it's less obvious that this applies
> to kdecore.

Sure, well that's up for discussion of course. Why do you say that? Because 
kdecore depends on qtcore and little else? Why does that matter? Can't we 
have the 'lowest level' libraries in kdelibs depend on QtXml, QtGui 
QtDeclarative etc - ie any parts of Qt. Does the 'lowest level' kde gui 
library/classes have to depend on kdecore for some reason?

> 
> yes, there are different kinds of things in kdecore, but there are both
> interdependencies and the open question of how many of those basic items
> does a typical application end up using. there's little point in splitting
> it up if a significant % of apps will use a significant % of features
> together from that library: they'll just end up linking to all the smaller
> libraries individually and we'll end up with a more complex system to
> maintain.

Sure, I get the complexity argument. It would take more buildsystem stuff to 
maintain, but the thinking was towards the 'Qt developers' like Gregory 
Schlomoff who think it makes more sense to fork and extract kimap/kmime/kjob 
than to simply depend on them as is. I agree with him that currently the 
forking like that makes sense for Qt developers, but I think it's changable.

You might think in terms of how much a typical KDE application ends up 
using, but I'm thinking in terms of how much a typical Qt application ends 
up using. Gregory is not going to end up using KLocale KConfig KDateTime etc 
just because he wants to use kimap. I'm thinking in terms of the Qt 
community and broader appeal - the people I interact with on qt-interest, 
not the KDE community.

For KDE applications I don't see anything changing. ${KDECORE_LIBRARIES} 
would be expanded to contain libkjob.so libklocale.so libkitemviews.so etc 
to whatever granularity makes sense.

> 
> imho what kdecore can benefit from is streamlining the KDE-only details in
> it, such as the global ref/deref and other such things. 

I'm not sure what you mean by streamlining here? You mean streamlining to 
mean getting supportive API into Qt for this kind of stuff?

> this should help
> make it smaller and get the lines between it and QtCore a bit more clear
> and clean. the ultimate goal of splitting out KJob, though? personally,
> i'm less convinced.
> 

My ultimate goal is to reduce 'uncle dependencies' and artificail 
dependencies of classes and functionalities and libraries in kdelibs and 
make it easier for those functionalities to be used by the broader Qt 
community. The goal is to make forking make less sense than as-is 
consumption. I know of 4 Qt based email solutions. Why don't they all use 
kimap?

There's also a lot of other useful stuff in kdepimlibs which doesn't need to 
depend on all of kdelibs as it currently does. Do you think a Qt-only 
akonadi client library would be useful? I do. Most of the classes in akonadi 
that are useful for implementing akonadi clients have only Qt class 
dependencies (like the model view stuff etc). KJob is the only part of 
kdelibs that the core functional parts of libakonadi really need.

By uncle dependencies by the way I mean - kjob and related classes do not 
depend on gettext. Those classes are in kdecore. KLocale is in kdecore. 
KLocale depends on getttext. kjob depends on gettext by association with 
klocale through kdecore, so gettext is an uncle dependency of kjob.

The 'artificial' dependencies of kdeui/itemviews are far more, though 
there's no dependence of that stuff on anything but Qt.

Thanks for your feedback on this by the way. It's useful to get others 
talking on it. I'm going to continue to try to be at 1.0 on the spectrum of 
wanting a granular kdelibs - to the point of playing devils advocate if 
needed :). I know that others have differing viewpoints, and that's great.

All the best,

Steve.