A Qt replacement for KGlobal::ref and deref

[Stephen Kelly]

Alexander Neundorf wrote:

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

Here's a picture of what I think kde looks like to a Qt developer:

http://steveire.com/kdelibs-current.png

It all converges to a point. It's an inverted pyramid.
Lots of stuff depends on each other, even just by association (like the 
itemviews stuff - the classes themselves only depend on Qt, but by being in 
kdeui come with a lot more baggage).
I know there are several entry points - you can use kdecore independently of 
the rest, even kdeui only needs kdecore etc, but in practice Qt developers 
fork what they want instead of depending on it.


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