Answering Cornelius and Alexander here.

Cornelius Schumacher wrote:
> I know what you think ("madness", "no", "KDE 5", "impossible",
> "governance", "binary compatibility", "Nokia", "impossible", ...), but if
> you put that aside for a while and think big, wouldn't that be a wonderful
> answer to all the struggles we have with kdelibs?

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.

> We all love Qt, without it KDE wouldn't exist. We also love the KDE
> development platform, it provides all that what Qt doesn't have or didn't
> have at some point in time. But is there still a real reason to keep them
> separate? Wouldn't it be much more elegant, if you wouldn't have to
> decide, if to use some KDE classes or write a "qt-only" application, if
> you would get all the wonders of KDE from Qt in one consistent way?

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.

> We would reach way more users. We could much more easily
> acquire contributors.

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

> Over the last couple of years, KDE development has constantly shifted from
> library development to application development. Our struggles with even
> just doing the basic maintenance of the libraries show that. But we have a
> lot of shiny apps, people are excited about being part of our
> subcommunities centered around applications. There are still brave souls
> taking care of kdelibs, but it's really hard to keep up there.

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:
> I would love to use some libs from KDE at work in a Qt-only project.
> First candidate is kio, several widgets, the file dialog.
> But, I can't recommend this.

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.

> A good thing still might be to reorganize our modules (it's quite long
> that we discussed this the last time ;-).
> Into some part which doesn't bring many additional dependencies (widgets ?
> kio ? date and time ?) and some part which is more complex (desktop search
> ? pim ?).

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

> But then again, the email address parsing from kdepimlibs probably doesn't
> have any dependencies, while maybe some widget where it is not obvious
> immediately drags in kwallet, dbus, etc.

These things belong in the platform integration level.

> Said that, I think the current setup with "kdelibs" and "kdepimlibs" is
> not optimal. I think either having more library modules would have its
> advantages (smaller, more targeted modules with less dependencies than the
> whole thing), or also moving kdepimlibs into kdelibs would be better, then
> it would be at least consistent (everything is inside kdelibs). This would
> also move kdepimlibs from being "one step higher" than kdelibs to the same
> level as kdelibs, i.e. when you want to use it, you would not have to drag
> in kdepimlibs AND kdelibs, but only (a bigger) kdelibs. But maybe there
> stuff can be disabled, so you end up with less dependencies.

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