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. And that makes sense today.

http://dot.kde.org/2010/10/15/gregory-schlomoff-betterinbox-kde-development-
platform

Here's what I'd like it to look like:

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.

I'd like kdelibraries to be something Qt developers use and recommend. 
Currently they no neither. KDE should provide a set of high quality Qt based 
libraries, it should be to Qt what boost is to C++.

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

That's only a description of the platformy stuff. There is a lot of code in 
kdelibs which provides functionality - not platform integration which you 
are describing. There's no need for the functionality parts to depend on the 
platform integration in all cases (in some, yes).

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

I'm not certain I understand what you say here.

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

I would say the current grouping reflects dependencies and level of 
integration, rather that functionality.

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

KDE applications are applications which use the platformyness in my opinion 
and the platform integration. KAboutData, KApplication, KComponentData etc.

Qt applications using the non-platformy kde libraries would just be Qt 
applications with sense :)

Steve.