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