1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

KDE Developers Discuss Merging Libraries With Qt

Qt

Published on 31 October 2010 11:03 AM EDT
Written by Michael Larabel in Qt
52 Comments

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

Cornelius had written a mailing list message summarizing this proposal of merging the KDE libraries with Nokia's Qt libraries. Here's some of his other quotes from this message:
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? What's the future of the KDE development platform long-term, independent of Qt?

There are probably a hundred times as many Qt developers out there than KDE developers, and if Nokia is only half-way successful with their plans for Qt, this ratio will continue to change rapidly in favor of Qt. By merging the platforms we could turn all these Qt developers into KDE developers. We could benefit from and contribute to the success of Qt without restrictions. We would reach way more users. We could much more easily acquire contributors.
...
On the other hand Qt has broadened a lot, and recently with the ambition to provide a full API for MeeGo this has accelerated. That's a bit similar to what KDE did quite some time ago. There is more and more redundancy and overlap between Qt and KDE libraires, and we still don't really have a good answer to that. A merge would be an answer, a big answer.

The KDE desktop and Plasma would effectively stay the same, along with the KDE applications, but all of the KDE libraries would end up becoming Qt libraries. Some developers agree with Schumacher's proposal and view it as a good vision for the future of KDE, but there are some mixed feelings such as those expressed by Alexander Neundorf. "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."

KDE's Mark Kretschmann, the founder of the KDE Amarok project, had this to say about the proposed idea of merging the KDE libraries into Nokia's upstream Qt:
Cornelius,

I must say: Kudos to you. You made my day.

What you have proposed is one of the smartest and most groundbreaking ideas I've seen in a long time. Admittedly, it sounds crazy at first sight. And I talked to some fellow KDE developers who were very skeptical about it.

However, there was a time when a certain Matthias Ettrich invented KDE. You know what people said when he published his idea?

"It cannot be done."
"No way."
"Impossible."

Look at what has become of his "little idea" now. And think about it: Most really great ideas start like that, with people being skeptical, just because it's new and needs getting used to. Cornelius's idea might be daring, but it is worth giving it some really deep thought.


PS:
Chani, thanks for bringing up this topic. A much needed discussion, and very useful too.

Other developers such as Albert Astals Cid, who maintains several KDE applications, feels though that Qt is not doing what they promised and are being naive. Albert even compares some of the shortcomings with the Qt project itself to what led OpenOffice.org developers to fork into LibreOffice. "Once this happens we can start speaking, anything we do now is wasting our time." Albert also does not agree with the Qt licensing requirements.

The original thread has already become quite lengthy, but this morning another thread pertaining to this discussion has been started and is entitled Cornelius's grand plan. In this second thread started by Mark Kretschmann, he said, "It's a very controversial idea. However, I think it is so refreshing that it deserves some more thought. Personally, I think the idea is great, if we can overcome some of the obvious road blocks. I would love to read some honest and direct thoughts from you guys."

There's many more posts in this second thread already and this discussion will likely continue to expand once the weekend is over. Some think this change could not even happen until KDE 6.0 if first the KDE libraries (kdelibs + kdesupport + kdepimlibs) are reorganized, which would lead to a binary compatibility break and thus KDE 5.0. Following the KDE5 library reorganization they could begin work on moving the needed code into Qt, which would break compatibility again and then create KDE 6.0 based atop a hypothetical Qt 5.0 release with these KDE library goodies.

We're still reading the flow of messages coming into both threads about this proposal and will add more interesting bits of information from both sides accordingly. Tell us what you think about this proposal by clicking on the comments button below.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  2. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
  3. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
  4. Sumo's Omni Gets Reloaded
Latest Linux Articles
  1. The Most Energy Efficient Radeon GPU For AMD Linux Gaming
  2. 20-Way Radeon Comparison With Open-Source Graphics For Steam On Linux Gaming
  3. Preview: OS X 10.10 Yosemite vs. Ubuntu Linux GPU Performance
  4. Radeon Graphics Yield Mixed Results With Linux 3.17 Kernel
Latest Linux News
  1. Ubuntu's Utopic Unicorn 14.10 Beta 1 Released
  2. Genode OS 14.08 Has New GUI Architecture, Pluggable VFS
  3. Another Intel Linux Power Regression Is Being Investigated
  4. DNF Makes It A Step Closer To Replacing Yum On Fedora
  5. OS Battle: Linux Takes 1.7% Desktop Marketshare
  6. PHP 5.6 Officially Released With New Debugger
  7. LibreOffice 4.3.1 Released
  8. Re-Clocking Your NVIDIA GPU With Nouveau On Linux 3.17
  9. Radeon DRM Queues More Changes, RV6xx UVD For Linux 3.18
  10. Metro 2033 Redux Will Hopefully Hit Linux Real Soon
Latest Forum Discussions
  1. Canonical Joined The Khronos Group To Help Mir/Wayland Drivers
  2. Users defect to Linux as OpenBSD removes Lynx from base system
  3. Best Radeon for a Power Mac G5?
  4. OC capability - Intel Core i5 4690K & Biostar Hi-Fi Z97WE
  5. Updated and Optimized Ubuntu Free Graphics Drivers
  6. AMD Releases UVD Video Decode Support For R600 GPUs
  7. Announcing radeontop, a tool for viewing the GPU usage
  8. It's Now Possible To Play Netflix Natively On Linux Without Wine Plug-Ins