A Qt replacement for KGlobal::ref and deref

[Alexander Neundorf]

On Monday 14 February 2011, Stephen Kelly wrote:
> 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.

Can you try to add some graphic to the tier 0/1/2 explanation, or elaborate it 
a bit more ?
I have a hard time understanding it exactly.

> > 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?

I think they depend e.g. on KDE-wide settings like single vs. double click, 
completion, translation settings, ...
Haven't actually written any C++ code for KDE since I'm caring for the 
buildsystem...
Anyway, if such dependencies are inside the K-classes, it should be possible 
to refactor them out, so these settings are set from the outside (wrapping 
class).

...
> 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.

By doing that, the borders between the KDE- and Qt-communities would blurr, 
which would be a good thing. I'm all for it.

> 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.

I guess we need to figure out groups which make sense.
I.e. making lists of classes which belong together in some way 
(functionality ? dependencies ? level of integration ?)
At least functionality wise they are already grouped quite well by the 
subdirectories inside kdecore, kdeui, etc.

> 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.

I mostly agree with you, but we shouldn't go to far with splitting.
Making more stuff available for currently-not-KDE programs would be good.
Well, then these programs would use low-dependency-libraries-provided-by-KDE, 
which would make them kind of KDE programs... ;-)

Alex