KDE Developers Discuss Merging Libraries With Qt

[cruiseoveride]

KDE has serious usability issues and GNOME is so simple its frustrating to use sometimes. People need to pick one and concentrate development.

[Teho]

That won't happen. Both environments have different kinds of desing phisolophies and one is written in GTK and the other in Qt. People don't just magically learn new toolkits, voluntary developers develope what they want to develope that's why there always will be atleast two different large scale desktop environments and bunch of small ones.

For example KDE doesn't want to hide settings, Gnome has opposite idea and hides everything they can. KDE tends to do more powerful apps and Gnome keeps it simple. They have incompatible HIGs and developemt platforms. To sum it up, you can't just abandon one.

[NoEffex]

No because of the non-KDE Qt desktop environments present and future.

[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.

[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.

[energyman]

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

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

[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?

[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.

[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.

[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?