Replying to John and Kevin here.

John Layt wrote:

I have wanted to write this down in words for some time, so here it is:

http://techbase.kde.org/index.php?title=Projects/KDELibsModifications

I would say make the split stuff available in KDE4 as KDE5Support. Then we declare KDE5 when the apps are ported and remove the KDE4 stuff. It's an option at least.

Cool. KLocale is an area I know very little about, but I want to change that. Actually one of the reasons I'm interested in splitting kdelibs is so that I can think about using it in Grantlee.

I counter-proposed merging kdesupport into kdelibs. I think in some cases, libraries went into kdesupport because they were functional, rather than platformy, so their authors didn't see any sense in adding the platformy dependency and baggage. That happened in the case of Grantlee and others too I'm sure. If something like Tier 1 existed when I started that, I would have put it there.

Having those things in a group we call kdelibs makes the release, promo and i18n machinery available to them as well as actually being part of the KDE community produce.

It seems many packaging and distribution problems either fall away, because the author controls both, not a distro and not the user, or fall away because they exist and must be solved anyway if Gregory-the-Qt-developer or ACME Qt-using software vendor is creating software.

Right. But if split well, it might always be obvious where things belong.

Kevin Ottens wrote:

To some extent I think this is already happening with kdesupport and the number random git repos growing.

As Jaime notes though it might be possible to build the libraries together if CMake'd from kdelibs/ and also make it possible to cd kjob && cmake. I'm not certain it's possible or sensible. Just another option.

Kevin Ottens wrote:

These kinds of things would of course be better, but would require API removals and replacements in Qt. Those kinds of things can only be done by someone with a maintainer hat.

Even running at full steam, I don't think open governance will lead to anyone outside of Nokia to maintain anything in QtCore or QtGui. I think the decision to make Qt depend on gettext etc would need to come from within Nokia. I've discussed this to various extents with some trolls too.

Some of the stuff is getting in to Qt, but the copyright of the submitted classes needs to be clear. Whoever puts KIdentityProxyModel into Qt for example must have the authority to let Nokia redistribute it under other licenses. Many of the older libraries don't have such clear ownership.

Albert Astals Cid wrote:

If we can find out what those useful things are we can move them to the platform level where they are still useful, right? Or make kio depend on the libraries that provide those useful things.

But you're right. Splitting like this will make keeping the same features harder (but not impossible) and would be a lot of work. More interdependence between libraries is easier, but makes independent reuse much harder. We just have to find out if it's worth it.

I think the interdependence of the libraries to each other and the platform is icky though. That's the main reason I make noises towards splits.

All the best,

Steve.