Matthias Ettrich: Integrating Qt Apps with KDE

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.

From: Matthias Ettrich <ettrich@trolltech.com>
To: kde-core-devel@kde.org
Subject: Qt-only KDE applications
Date: Tue, 22 Jan 2002 13:45:39 +0100
X-Mailer: KMail [version 1.3.8]

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?


KDE has always been a platform on top of X11. KDE is sometimes refered to as not only a DE but as an development platform.

So I don't se a problem whit this if you are running the Qt apllication on
an inferior platform:) Gnome/Windows/Mac/X11-only you get the same functioality.
You don't lose any, but on the superior platform KDE, you get the added functinality KDE provides.

By Morty at Wed, 2002/01/23 - 6:00am

Why does kde uses the qt layer in back?

Qt have many classes that a kde-program newer will use, it only waist memory!

why dont strip out all unnessesary classes from qt and put them into libkde.so ?, It will save you memory, and improve startuptime!

Then you can make a kde-libqt.so that is a qt-compatible library.

Sorry for my realy bad english.

By Jimmy W at Wed, 2002/01/23 - 6:00am

Well, KDE uses a lot more of Qt than you may think, but it is a valid option for KDE to fork Qt.

There's one big problem though: licensing. Right now, KDE isn't committed to either of the Qt licenses, so KDE isn't tied to the GPL license Qt offers. If KDE were to fork Qt, then KDE would have to use the GPL. This would severely limit the licensing options of KDE apps, and damage KDE development momentum.

On the other hand, it'd put the community firmly in control of its core library.

Ultimately what will keep KDE from forking Qt is the amount of work involved. Until a fork of Qt is actually made by somebody, and that fork gives a compelling reason to switch, it's just not going to be worth the effort in the eyes of most KDE developmers.

By Neil Stevens at Wed, 2002/01/23 - 6:00am

Since GPL QT only allows you to link against GPL programs, you could not write programs for it using other open source licenses. I consider that a big drawback.

By ac at Wed, 2002/01/23 - 6:00am

Hi! I am not sure if all developers or companies will use a libQtKDE.
Might it be possible to use LD_PRELOAD to catch libqt calls? This would be very cool

By Henning at Wed, 2002/01/23 - 6:00am

Wow, the discussion has sort of went all over the place. And Ben, your posts are way too long :P

Anyhow, it seems there are two ideas floating around.. let me re-iterate what people are saying, and then I'll give my take.

A) KDE should become another platform for Qt (which is circular, as Matthias put it), just like Windows and Mac.

B) kdelibs should be more portable, so that people may use them on other Qt-supported platforms.

Both of these are good ideas, but they are both very different as well.

I really like (A). Just look at the FileDialog. On Windows and Mac you get the native dialog. On KDE you get a stripped-down Qt-based one. This is ironic, because it means KDE is the least supported environment by Qt. As KDE grows and takes over the Unix desktop (IMO, of course), potential customers of Trolltech are going to find that the lack of KDE support in Qt makes Qt/X11 less viable. X11 is barely a desktop platform. Why should there not be Qt/Windows, Qt/Mac, and Qt/KDE ? And what Matthias talks about is doing it via a plugin, so that all you hardcores out there that want Qt/X11 would still be able to have it. Qt/KDE would be a bonus.

(A) is helpful to Trolltech, because it makes Qt more viable. It is also helpful to application developers, like myself, who use Qt for both Windows and X11. Why should my app work best elsewhere? I want it to work best on Linux/KDE, my primary platform!

I have less to say about (B), since it is a more clear argument. Basically, it says we should take KDE everywhere. This makes it a library layer on top of Qt (which it is) that application developers could use wherever they go. This is not a bad idea, although it makes KDE seem like less of an integrated desktop if it is so movable like that. KDE layered over X11 isn't quite so bad, since there really isn't anything to X. But layering KDE over Windows could be strange. Users might not understand why their FileDialog looks so different.

If you haven't figured it out from the above text, I choose (A) as the route of choice. The downside people have mentioned are that developers wouldn't use specific KDE-API's since they would be trying to maintain a cross-platform app. This is true, and is no different than avoiding direct use of the Win32 API either. However, I don't think there is anything wrong with an #ifdef here or there. I already do it for enough things on Win32 and X11 (like user-idle, system tray, etc), do you think it would stop me from adding KDE specifics as well? Absolutely not, I am just waiting for KDE3 :)

But a proxy library "libQtKDE" would make commercial developers more interested in using KDE-specifics, since otherwise they need multiple binaries.

By Justin at Wed, 2002/01/23 - 6:00am

Ok, so the first comment was way too long and a bit wacked. But as stated in my second long post the problems comes from developers who have (or want) to cross-developer, but dont' care to have hundrededs of ifdefs around places that use kmainwindow vs qmainwindow and other simple stuff. Why can't those ui classes be taken out of kdelibs and made cross-compilable in their own lib? In the windows version it will use windows file dialog and in unux it would use kde's. They they are not hindered about which the widget set to use.

-Benjamin Meyer

By Benjamin C Meyer at Thu, 2002/01/24 - 6:00am

"In the windows version it will use windows file dialog and in unux it would use kde's. They they are not hindered about which the widget set to use."

Note that if you are developing primarily for windows (with the linux/mac port a bonus), I see very little incentive to use the kdelibs extenstions as Qt already has native dialogs under Win32.

By drawoc suomynona at Thu, 2002/01/24 - 6:00am

Point taken, but those are not the primary target of this. The primary target is all of the little open source projects that were created to run under linux, but are kept qt only so that they will work under windows.


By Benjamin C Meyer at Thu, 2002/01/24 - 6:00am

> Users might not understand why their FileDialog looks so different.

Just a suggestion: What if one would port the kwin window manager to Win32 and use that as an alternative shell for windows (instead of explorer). LiteStep and others take this approach, why couldn't KDE? I think the portability of it all can do more good than harm.

Just my two bits,

By Coolvibe at Sat, 2002/01/26 - 6:00am

The implications of basing KDE on Qt have been described before. Using Qt for KDE has been a good solution and probably will be a good solution for some time, but earlier or later KDE should get its own toolkit. This is of course a big task, but has to be done, its inevitable. This doesn´t mean all work on KDE3.0 should be halted, but one should aim at a replacement in a few years. The KDE developers have already shown that the can create a good framework. Why not carrying on extending it until Qt is obsolete. lib by lib, class by class.


By Marc at Wed, 2002/01/23 - 6:00am

>Why not carrying on extending it until Qt is obsolete. lib by lib, class by class.

That is not the right question.

The right question is why, not why not.

By Roberto Alsina at Wed, 2002/01/23 - 6:00am

Nobody is motivated to do it, since there is no real reason to do it (no "pain pressure").
Replacing Qt would be a huge task, and Qt is GPL'ed, you could simply fork it, but then you would loose all future developments of Qt.

If you want to, do it, nobody keeps you away from doing it.


By aleXXX at Fri, 2002/01/25 - 6:00am

I absolutely adore the KDE file dialog. Funnily enough, it's one of my favorite
parts of KDE. I HATE using a Qt file dialog, after using the KDE one it's
sooo frustrating.

By TomL at Thu, 2002/01/24 - 6:00am

For the Gnome desktop, GTK applications integrate naturally (such as "the Gimp"). Why not provide the same functionality to KDE ?

Apart from the technical discussion, I'm considering "the growing number of cross-platform but Qt-only applications becoming available" that would benefit from it.

There are already "The Kompany" products (as highlighted by Shawn Gordon) and the most obvious to me are:
- Avifile
- Qcad.

I hope others could complement this list with Qt applications they love, use often & would greatly appreciate to integrate better in the KDE desktop.

By Phil Ozen at Thu, 2002/01/24 - 6:00am

In the workplace shell you could insert a new class/object into an already existing (even running) inheritance hierarchy!

When Windows 95 entered the scene with the famous X to close an application - a Xit application that inserted itself (read KApplication) above Object class (QApplication) showed up within a few days. This worked for ALL programs AND folders!

Couldn't this be done with Qt only applications? You are able to replace system calls via weak(?) linking...

[checkout Stardock - started with games and Object Desktop for OS/2 (zip folders, etc...)
now they try to provide the same thing to Windows


By RogerL at Sat, 2002/01/26 - 6:00am