KDE Developers Discuss Merging Libraries With Qt

[mystique_fusion]

Too lazy to read the linked mailing list threads yourself?

Not quite! The discussion on the threads has stopped some days now. I wondering whether there is any progress somewhere else.

[KAMiKAZOW]

I like this idea because it might help to modularize KDE. People wouldn't necessarily have to run Plasma, Nepomuk/virtuoso/, kwin if they didn't want to. Right now it's a serious disadvantage that if you want the benefits of KDE features, you almost have to run all or most of KDE - or at minimum have it installed.

This happens when people don't get the year old memo about KDE?s rebranding.
Some people treat the rebranding as needless nitpicking but if the correct names were used your confused knowledge wouldn't have happened in the first place.

So to make things clear for you:
1.) KDE is an organization, not software.

2.) KDE releases three pillars of software every 6 months: Platform, Workspaces, and Applications.

3.) Applications and Workspaces are completely separate. KDE Applications only require Platform, not the Workspaces. And likewise Workspaces don't require any KDE Applications.

4.) KDE Platform contains the foundation for all KDE software, including the Plasma base library that's ~3MB in size. The whole KDE Platform (without Qt) is only ~35MB in size.

5.) The KDE Workspaces contain Plasma Desktop, KWin, power management, etc.

6.) Since KWin and Plasma Desktop are in a package on which no KDE Application depends, your comment is simply wrong.

Any news on that front? Is there any conclusion on what kind of strategy KDE will follow?

Too lazy to read the linked mailing list threads yourself?

[mystique_fusion]

Any news on that front? Is there any conclusion on what kind of strategy KDE will follow?

[Goderic]

KDE seems to be moving towards greater integration with plasma, kwin, and various other dbus protocols with special KDE-specific support for things like the system tray. There are certain functionalities that you can only get inside KDE due to the backend services running in a KDE environment.

There's also as mentioned a size and redundancy penalty. Different incomparable systems implemented in both QT and KDE which serve essentially the same purpose. Users and developers have to choose and make compromises.

If everything became a part of QT, then it wouldn't be much of a decision whether you want to install it in order to gain support for certain applications. They just become features of the widget toolkit. People on various platforms are much less likely to want to install KDE in addition to QT in order to run say digikam for example.

Strange.
I was under the impression that KDE was moving to be more an compilation of apps which can work great on any platform, GNOME, KDE and even Windows. And not just being a DE.


Anyways, was the whole idea of DBus not being more DE independent?

[Smorg]

You can now easily use all KDE and (other) Qt apps on GNOME, why would that change when you merge KDE into Qt?

KDE seems to be moving towards greater integration with plasma, kwin, and various other dbus protocols with special KDE-specific support for things like the system tray. There are certain functionalities that you can only get inside KDE due to the backend services running in a KDE environment.

There's also as mentioned a size and redundancy penalty. Different incomparable systems implemented in both QT and KDE which serve essentially the same purpose. Users and developers have to choose and make compromises.

If everything became a part of QT, then it wouldn't be much of a decision whether you want to install it in order to gain support for certain applications. They just become features of the widget toolkit. People on various platforms are much less likely to want to install KDE in addition to QT in order to run say digikam for example.

[Smorg]

I like this idea because it might help to modularize KDE. People wouldn't necessarily have to run Plasma, Nepomuk/virtuoso/, kwin if they didn't want to. Right now it's a serious disadvantage that if you want the benefits of KDE features, you almost have to run all or most of KDE - or at minimum have it installed.

My support for this measure would greatly depend upon whether Nokia decide to be douchebags. I would want clean integration with QT without having to make too many technical compromises. Cutting down on redundancy would be great, and even beneficial to Nokia because they would automatically inherit a lot of KDE applications.

[Goderic]

And for (b), you end up with something like :- a KDE API uses one or more KDE daemons, such as knotify, or kded, or nepomuk. To properly support the API, it has to start the daemon. So you're running your GNOME desktop happily along, and next thing you know, half of KDE's daemons have started in the background! But since you aren't running a proper KDE session, you get weird errors, like things assuming they can talk to kwin/plasma when in fact kwin/plasma aren't running, and so on and so forth.

You can now easily use all KDE and (other) Qt apps on GNOME, why would that change when you merge KDE into Qt?

[energyman]

Imagine if the GNOME guys talked about merging gtk3 libs with GNOME libs...

funny, isn't that exactly what is happening today?

[V!NCENT]

In the end it's leting Qt do anything abstract and KDE do their thing and heavily reducing code to maintain. Let Qt do their pro skills on some previous KDE stuff and make KDE less buggy.

KDE4 is too advanced to maintain, just like HURD. Chaos theory. It must go on a complexity diet.

[curfew]

You are so wrong now.
Here is how it really works.
SOME KDE developers are SPONSORED by Qt and some other KDE developers work for Qt. Or you can turn it the other way around. Some Qt developers also work on KDE. But it's certainly not the case that Qt points and KDE leads.. hell no! Remember phonon? It was developed by KDE devs and adapted by Qt because it was simply good.

Qt doesn't sponsor anyone. Qt is a software toolkit developed by Trolltech, later bought by Nokia.