AUG
8
2004

KApplication dependency sucks

Submitted by krake

Caution, rant ahead!

I started working on an extension library for Qt applications which should enable them to use service or features offered by desktop APIs without creating link time dependencies on the respective desktop libs. http://www.sbox.tugraz.at/home/v/voyager/qds/index.html

My special interest was to have access to KRun and the KIO functionality under KDE. Latter for pure coolness, first for things like "launching the default browser".

All went fine at first, I managed to hack some framework stuff that also compiled and ran on Windows.

But when attempting to use KRun from a Qt application I failed miserably.
KRun requires that a KApplication instance exists!

I had a quick look at the relevant sources to see if this could be worked around by forking some code but then decided to tackly KIO first.
KIO is even worse. One would have to reimplement almost all of the client side code of KIO.

So I ended up with a hack: the KDE plugin has a property telling the application that it needs its own QApplication subclass running and can create one on request.
This effectivly restricts the usefulness of QDS on KDE to applications which don't require own QApplication subclasses.
Granted this should be the majority of apps, never the less it makes the library handling artificially complicated.

Comments

Could you explain this a bit more? When I read your post it sounded like you were trying to use this to run KDE applications on Windows without using cygwin.

By Mark Bucciarelli at Tue, 08/10/2004 - 18:31

I'll try to explain more clearly:
I started writing a library which offers services, which can be found in desktop APIs, to Qt applications.
An example would be a mechanism to start the defaul viewer application for a given URL.

Those services are implemented in plugins.

A plugin based on KDE's API should use KRun for the viewer launcher mentioned as an examples service above.

Unfortunately KRun's code depends on kapp pointing to a valid KApplication instance.
A portable Qt program usually does not have a KApplication instance, so in order to use the KDE API the plugin has to create the KApplication itself, requiring extra code in the program using my library and making the KDE plugin unusable for programs that need their own QApplication subclass.

By krake at Thu, 08/12/2004 - 19:35