Answering Cornelius and Alexander here.

Cornelius Schumacher wrote:

I don't think so.

There will always be a place for third party Qt-based libraries. That is what kdelibs should be. The kde platform should sit on top of those libraries. The kde platform will not become completely irrelevant because of integration points like action shortcuts, about dialogs, menu structures etc. It should be possible to use the libraries without the menu structures and about dialogs though.

1) Would KJob make sense to have in Qt directly? Probably. kdeui/itemviews? Parts of it, yes. And parts of it are going in to Qt.

2) What about KMime, KIMAP, Kross etc? Those are all domain specific libraries. Why should they be in Qt instead of third party libraries?

3) What about KDED, KLauncher, kdeinit, ksycoca? Those are all platformy kde specific things. They make sense if you are creating a large suite of integrated applications, which use the same libraries, which publish mimetype based capabilities of the applications for certain tasks. Most Qt developers don't make a large suite of hundreds of applications. They make just one. They make the only one which is suited to the task it was written for, so they don't need ksycoca.

I heard there used to be a rule that API only gets into Qt if 80% of their customers would use it. I don't know if that has changed, but it might help answer the questions of 'Does this particular functional library in kde{pim,}libs belong in Qt?'

The things that fit into category (1) above correspond to the Tier 1 I described in the wiki. Category (2) is Tier 2, and category (3) corresponds to the platform Tier.

If you're talking about putting code into Qt to make is possible to use Qt APIs like QDateTime in our applications (and most importantly in our APIs), and have it JustWork with our platform like it does with KDateTime today, I'd say +1000. That needs to happen.

When the categories 1 and 2 are separate and below the platform, rather than on top of it, it doesn't matter whether they are in Qt or are a third party addon, such as my proposal for kdelibs. The separation of platform and libs is a prerequisite either way.

Another prerequisite IMO is to fix Qt enough so that classes like KUrl, KFile, KProcess, KDateTime, KWhatever are either not needed, or can be in the platform level. They create interdependence and are incompatible with creating Qt applications which use the functional libraries we have in kdelibs.

Which wonders? The libraries or the platform?

The fact is that kdelibs as it currently is is incompatible with Qt applications, and therefore many parts of it do not belong in Qt. It is in a walled garden. You can use use none of it, or you can use all of it, or you can fork the parts you want to use into your own build and integration system. That is why it is hard to use and hard to sell.

The future I'm talking about is one where Gregory can use the coherent functional libraries without using all of them, and without being forced to discard his own platform of settings and i18n etc in favour of the kde platform ones. And without having to fork them or the build system for them.

In fact, Gregory had forked kjob, kimap and kmime into a Hg repository complete with replacing KDateTime for QDateTime, kDebug for qDebug etc, and a qmake build system before I told him that was probably not needed. That is even one of the most sensible ways of using the functional libraries of kdelibs today if you ask me. Isn't that a bad situation? The large pool of Qt developers can't see over the walls into our beautiful garden without a little help from one of us.

Wouldn't this be true if kdelibs was 'a set of Qt-based libraries which can be used in Qt-based applications'?

It doesn't seem so bad to me, but I haven't really been around long enough to have something to compare todays situation to.

Anyway, without knowing whether your talking about merging libraries or the platform into Qt, and what that even means, I don't know if what you're talking about is a good idea or a bad idea.

After that we can start listing obstacles :)

Alexander Neundorf wrote:

Exactly. Why should all of the libraries depend on all of the dependencies of all the other libraries? Why should a transparent network data transfer interface, some widgets and a file dialog depend on relational databases, semantic databases, string template systems, spell checking libraries and compression libraries?

That shouldn't be necessary of course and more modularity and encapsulation and less interdependence would make what you and others like you want to do possible. Then you wouldn't have to commit to the whole kde platform, maintaining its dependencies etc.

I agree. This is what I proposed on the wiki.

These things belong in the platform integration level.

We seem to agree with each other, but I get the impression that many people didn't read what I wrote in the wiki. Can we use that as a starting point for discussing any reorganization?

http://techbase.kde.org/Projects/KDELibsModifications

All the best,

Steve