Matthias Ettrich is proposing a new strategy for more strongly integrating Qt-only applications into KDE. It's an intriguing proposal and relevant to KDE, considering the growing number of cross-platform but Qt-only applications becoming available. The initial "not-perfect but simple" basic idea is that a small libQtKDE proxy library would invoke KDE functionality when available, or otherwise fall back to Qt functionality. This would not involve changing Qt or KDE, but would require the programmer to link against the libQtKDE wrapper. The benefits for the former Qt-only developer is that KDE functionality would be made available cheaply without giving up the Qt-only cross-platform approach. The benefits for the KDE user is that what would have otherwise been a pure Qt-only application could now potentially integrate much more strongly with KDE. Good thing or bad thing? Read on for the full details of the proposal.
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
- 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
Technically, the simplest approach does not even require changing Qt or
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
Opinions? Do you think that would be useful at all?