From kde-core-devel Tue Jan 22 12:45:39 2002 From: Matthias Ettrich Date: Tue, 22 Jan 2002 12:45:39 +0000 To: kde-core-devel Subject: Qt-only KDE applications X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101170367405607 Hi, some time ago there was a rant somewhere about the emerging number of cross-platform Qt-only application that do not use KDE's API and thus do not benefit from KDE's additional features on Unix. To make things worse, those apps - although using the same core toolkit - do not integrate much better into KDE than any other X11 application. Qt 3.0's style plugins will improve the situation somewhat, but not sufficiently. Here's a rough, non-complete list of features a Qt application should be able to utilize when running on a KDE desktop: - standard KDE dialogs: - file dialog - the amazing print system / printer dialog - color dialog - others (like the lovely about box) - network transparency via KIO - exporting interfaces via DCOP (thanks to the new way of handling signals and slots in Qt 3.0 this can be done with Q_OBJECT only, no need for dcopidl and friends) - access to standard icons and icon effects - obey other common settings for application main windows that go beyond the standard QStyle specification - use KDE's style hints even if qtconfig specifies something else One suggestion was to go cross-platform with parts of KDE and to promote KDE as cross-platform API as well. There's another solution, which I'd like to promote here. KDE from the perspective of a cross-platform toolkit like Qt, is really just another platform. Just as we use the standard MS-Windows file dialog on MS-Windows, Apple's on MacOSX, Qt should be able to use KDE's dialog when running on top of KDE. The main reason why this isn't so easy, is the circular dependency: Qt uses KDE uses Qt. However, we don't need to start with a perfect solution. If would be a major improvement already if we could make it _easy_ to use the above mentioned KDE features from otherwise Qt-only applications, without having to write/maintaining two different versions of your application code. Technical, the simplest approach does not even require changing Qt or KDE: We write another small library libQtKDE, that wraps KDE functionality. Either there exists two binary compatible versions of this library, one using Qt-only, one using KDE, or we make one version of the library that dynamically loads a KDE plugin when installed. The library contains a dummy application-class (so that it's possible to reimplement virtual QApplication functions) which instantiates either a QApplication or a KApplication. In addition there are a bunch of static functions like getOpenFileName, NetAccess::download, etc. Later, the static functions in Qt itself( like QFileDialog::getOpenFilename, QPrinter::setup, ...) could utilize the extended versions, but that's a second step. We could also provide cross-platform functions that instantiate an MSIE/ActiveX control on MS-Windows and a KHTML/Konqueror on KDE. An application using libQtKDE is somewhere in the middle between a standard Qt-only application and a true KDE application using the KDE API. But this is seeing it from the programmer's perspective. For the user, it will much closer to a true KDE application. Just that the same binary will run without having KDE installed - with a slightly different look and feel and less functionality. Opinions? Do you think that would be useful at all? Matthias