Qt KDE integration in kdereview.

Olivier Goffart ogoffart at kde.org
Fri Nov 6 19:51:18 GMT 2009


Le Friday 06 November 2009, Diego Iastrubni a écrit :
> Hi Olivier,
> 
> Why are you thinking about code duplication? Since KDE was started, we used
> Qt, and many times we say some missing parts in Qt, and we wrote them. In
>  the last few years some code started migrating back "downstairs" to Qt
>  (phonon, WebKit, lets say also "plastique" even though I am not exactly
>  right).
> 
> What concerns me about your response is that even if you duplicate KDE's
> behavior in pure Qt applications, KDE will not drop those classes, and my
> computer will get infected with code duplication. My real question was not
> about imitating KDE's look and feel in Qt applications, but about giving Qt
> the ability for KDE to inject some of it's code to live Qt applications.
> 
> I mean, the code is already written, all we need in theory, is some glue.

Several problems:

 - Qt has to work without KDE, and many of the KDE code has more KDE 
dependences.  This is perfectly fine within KDE, but does not make it easy to 
integrate into Qt.
 - When being introduced into Qt the API has to change. Not only s/Q/K/ for 
all classes, but API reviews will most probably change lots of things. But KDE 
has to keeps (binary) compatibility with previous version.
 - Licence problem: We want to continue to have a comercial licence of Qt.


So the features, when moved from KDE to Qt, are not 100% compatible. And the 
glue code has to be done by KDE.

Exemple: In Qt 4.5 the QTabBar saw lot of improvements. From the ability to 
close the tabs to the ability to do drag and drop.  Some of the new feature 
were already present in KTabBar. The KTabBar could then mark some of the 
function as obsolete,  but could not completly remove the code since it has to 
keep binary compatibility.





More information about the kde-core-devel mailing list