"Cornelius's grand plan" - Merging KDElibs into Qt
steveire at gmail.com
Sun Oct 31 18:41:28 GMT 2010
Mark Kretschmann wrote:
> What do you think about it?
Let's merge Qt and the KDE development platform. Let's put all KDE
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.
Obstacles to getting most of kdelibs wholesale into Qt (or close to it):
1) Qt is moving in the opposite direction, even proposing separate repos for
Qt based modules developed in-house, like QtMultimedia, QtQuick etc.
2) APIs in kde platform are not all compatible with the goals and quality
standards of Qt. Some kde stuff is there for nepomuk or akonadi features for
example. Such things would only be put into Qt if they were compatible with
the goals of Qt. Additionally, putting all of the functional libraries of
KDE into Qt would significantly increase the bloat and dependencies of Qt.
The modular Qt of the future is a lean mean framework for creating
libraries, applications and platforms and some additional modules released
3) The license and copyright assignments are incompatible with KDE library
code. Rather than being 'merged into Qt', features would have to be
rewritten Chinese Wall style.
4) Push access to the Qt repos is not currently available, but lets assume a
world where is available for established contributors. Everything still
would need pre-review, whereas in KDE we mostly do post-review. New
contributors would have to use the Merge Request system, or some other form
of pre-review for all patches until they are trusted enough by Nokia (not by
the KDE community) to push themselves. This raises the barrier to entry.
5) Any code shipped in Qt by Nokia has maintenance and compatibility
guarantees that would need to be satisfied by the KDE community, even on
platforms many KDE developers don't know much about, like Symbian. That's
not really a guarantee that a FreeSoftware community can make.
6) Release schedules of Qt may not suit the goals and needs of KDE
applications and release cycles.
7) We're a bit low on concrete details about what would happen specifically
to specific classes and libraries. Someone needs to start creating an
How many of the above obstacles are solvable?
All the best,
More information about the kde-core-devel