On Mon, Dec 12, 2011 at 8:24 AM, Gravis <kde-de...@adaptivetime.com> wrote: > there are a lot of basic and advanced things in Qt that KDE isnt using > but using their own implementation or variant. this may be an issue of > code being merged into Qt and the KDE code not being deprecated but i > can't say for certain. > > -Gravis
Just because there are libraries in KDE and Qt with similar names does not mean the two libraries provide the same features or same capabilities. In a lot of those cases, maybe all of them, it is more a case of the Qt version not having features that the KDE applications need. With Qt5 and open governance it is possible to merge those features into Qt, and that is one of the primarily goals for frameworks. However, this often cannot be done without breaking backwards compatibility with both KDE and Qt, so it is not something done lightly. You can't just outright replace the Qt version with the KDE version, since that would break things for other Qt users (the KDE and Qt versions can have wildly different APIs), and it may lose features or performance benefits the Qt version has that the KDE version does not. Or the KDE version may not be optimal either, so it is better to plan ahead and make something better than both. Whatever the case, it is not as simple to just switch to the Qt versions of libraries as you make it out to be. There are different KDE and Qt versions of libraries precisely because the KDE and Qt versions are not equivalent. If they were, the KDE versions would be marked as deprecated. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
