why kdelibs?

[Stephen Kelly]

Replying to John and Kevin here.

John Layt wrote:
> Some excellent points, and it makes clear the sort of areas we need to be
> working on.  Currently choosing to use kdelibs or any other KDE library
> just as an extra Qt module usually means more pain, not less, which really
> should be our selling point.
>
> Do we have a wiki page were 'what can be fixed now' and 'what needs fixing
> in
> KDE5' has been/can be written down?  Perhaps a version of
> http://techbase.kde.org/Projects/Mobile/PlatformModifications but with a
> little more detail?

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

>
> While a lot of the dependency fixing would break BC and so can't be done
> in the KDE4 SC, I suspect a lot of 3rd parties would actually ship their
> own copy
> of of what they use anyway, rather than using shared libraries?  In which
> case we can do compile time switches for them to just get what they need
> without
> all the other stuff?  Of course there would be a lot of work providing the
> alternative paths, but it would be in preparation for KDE5 and thus less
> work to do then?

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.

>
> For example, KLocale needs KConfig on KDE platform to load the format
> settings, but a Qt program would not want those settings so a QLocale
> backend
> could be used instead and thus remove the need for KConfig.  In fact,
> KLocale is a problem as if you don't have kdebase/runtime/l10n installed
> you get the C locale, and even if you do have the files there's no
> guarantee they will be the same as what QLocale will return for the rest
> of your app, or what your Win/Mac/MeeGo/Gnome system settings are. I'm
> working on that.

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.

>
> For those libraries like KIMAP and the itemview stuff that don't really
> need kdecore/kdelibs stuff at all perhaps kdesupport is the right place
> for them? Perhaps the 'K' name is also an issue, if they don't need K
> stuff, then just
> call them QSomething or a funky non-K name?  From a promo point of view,
> we could then advertise libraries as being 'By KDE', 'Using the KDE
> Platform', and 'For the KDE Desktop'.

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.

>
> The other issue is platform portability, stick with Qt and you know it
> works on every platform with no extra effort, even if the tools fall short
> in some
> areas.  Use kdelibs and you will have problems on Win and Mac trying to
> decide
> how to package and distribute.  Work is ongoing on Win to make it happen,
> but Mac appears to have stalled somewhat?

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.

>
> Of course, once the splitting work is done, and it's easily portable, then
> eternal vigilance is needed to make sure it stays that way, which probably
> means more stringent rules around kdelibs.

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

Kevin Ottens wrote:
> Note though that there's likely two things to keep in mind:
>
> a) We have to be careful to not split our libraries too much, if they
> become too small and too numerous we'll very likely pay it in
> application/workspace startup time on some platforms (definitely need to
> be carefully benchmarked and so on, there's a trade-off to find).

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:
> At the light of my points above, assuming open governance of Qt running at
> full steam:
>
>> KLocale: More powerful i18n than QObject::tr and friends. Based on
>> gettext.
>
> Why not push its features in Qt itself?
>
>> KConfig: More powerful settings management than QSettings.
>
> Why not improve QSettings to have it on par with KConfig?

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:
>> I'd love to see a time where we'll provide a KDE Platform neatly
>> abstracted away by Qt, and a KDE Libraries Collection which are add-on
>> modules to Qt. Most of what is in kdesupport these days qualify: QCA,
>> etc., it's time kdelibs gets cleaned up to reach a similar state.
>
> You can not create Qt add-ons and still be as good as we are right now,
> since what you suggest would mean that kio would not be able to use the
> useful things kdecore and kdeui provide.
>

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.