why kdelibs?

[Alexander Neundorf]

On Saturday 30 October 2010, Cornelius Schumacher wrote:
> On Thursday 28 October 2010 John Layt wrote:
> > Big questions.  Anyone with big answers? :-)
>
> Here is a big answer:
>
> Let's merge Qt and the KDE development platform. Let's put all KDE
> libraries, support libraries, platform modules into Qt, remove the
> redundancies in Qt, and polish it into one nice consistent set of APIs,
> providing both, the wonderful KDE integration, consistency and convenience,
> as well as the simplicity and portability of the Qt platform.

This sounds, well, at least interesting.
A very practical, down-to-earth issue is see there, are the dependencies.
For building Qt, you don't need a lot of stuff.
For building kdelibs, you need *a lot*.
When we want to keep the functionality we have, how to integrate that into a 
Qt module without making it require soprano, some databases, etc. ?

OTOH, maybe QtDbusMenu should move to QtDBus ? Would that be possible ?


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.
Wouldn't that make us depend on kdelibs, i.e. also depend on all the 
dependencies of kdelibs, and the full KDE startup to start our application ?
Our (proprietary) application needs to run also on e.g. RedHat 4 systems, 
where we can't expect that there is a lot of up-to-date software there.
I think this would add so much dependencies (for our application at work), 
that I/we am not sure we could promise that it will work everywhere and when 
something doesn't work, that we understand enough of the whole system to fix 
it.

Also, when we would do this at work, it would mean that porting our 
application to Windows would become harder. Right now we depend only on Qt. 
The biggest problem with depending on kdelibs on Windows wouldn't be kdelibs 
themselves, but all the dependencies of kdelibs, where AFAIK a lot of work 
has been spent by our KDE team to get them building and working.
And they usually built this with their emerge script, which is another 
relatively big/complex/magic piece of software (at least to me, but I 
actually don't know it), which we would rely on at work then.

> 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?
>
> 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?
>
> Sure, this would be a massive effort, and require huge changes, it would
> probably mean Qt 5 and KDE 5, it would take quite some time, it would need
> further changes to the Qt governance model, it would mean investments from
> Qt Development Frameworks, it would mean a long transition phase for
> applications to adapt. But wouldn't it be worth this effort?

Not sure. KDE 4 is still young, and I know many people who still prefer KDE 
3.x.
Announcing the next big breakage and 5 years of development for KDE 5 in the 
next two years or so might also be the death of the KDE desktop.

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 ?).
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.

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.

Alex