Announcement

Collapse
No announcement yet.

KDE Developers Discuss Merging Libraries With Qt

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic KDE Developers Discuss Merging Libraries With Qt

    KDE Developers Discuss Merging Libraries With Qt

    Phoronix: KDE Developers Discuss Merging Libraries With Qt

    Well, here's some interesting weekend news: there's a polarized discussion taking place right now among core KDE developers about merging the KDE libraries into upstream Qt. Cornelius Schumacher, a long-time German KDE developer and currently the KDE e.V. president, has come out yesterday saying, "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."..

    http://www.phoronix.com/vr.php?view=ODczOQ

  • mystique_fusion
    replied
    Originally posted by KAMiKAZOW View Post
    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.

    Leave a comment:


  • KAMiKAZOW
    replied
    Originally posted by Smorg View Post
    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.


    Originally posted by mystique_fusion View Post
    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?

    Leave a comment:


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

    Leave a comment:


  • Goderic
    replied
    Originally posted by Smorg View Post
    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?

    Leave a comment:


  • Smorg
    replied
    Originally posted by Goderic View Post
    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.

    Leave a comment:


  • Smorg
    replied
    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.

    Leave a comment:


  • Goderic
    replied
    Originally posted by allquixotic View Post
    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?

    Leave a comment:


  • energyman
    replied
    Originally posted by TemplarGR View Post
    Imagine if the GNOME guys talked about merging gtk3 libs with GNOME libs...
    funny, isn't that exactly what is happening today?

    Leave a comment:


  • V!NCENT
    replied
    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.

    Leave a comment:

Working...
X