Mark Kretschmann wrote: > What do you think about it? 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.
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. http://labs.qt.nokia.com/2010/10/26/qt-is-going-modular/ 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 synchronously. 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 annotated list. How many of the above obstacles are solvable? All the best, Steve.
