kdecore/util/klauncher_iface.h - why oh why?

Lubos Lunak l.lunak at suse.cz
Tue Apr 7 15:38:04 BST 2009

On Tuesday 07 of April 2009, David Faure wrote:
> On Sunday 05 April 2009, Lubos Lunak wrote:
> >  Hello,
> >
> >  could somebody please explain why kdecore installs and exports something
> > that - is internal API of KLauncher?
> It's the return value of KToolInvocation::klauncher(). It's used by e.g.
> slave.cpp to say KToolInvocation::klauncher()->waitForSlave(pid), or by
> kdebase/workspace/kcontrol/input/main.cpp to say
> KToolInvocation::klauncher()->setLaunchEnv(...). lxr.kde.org had such
> answers btw ;)
> So it's not internal API, it's indeed public API. KToolInvocation itself is
> supposed to be the public API for the startService* methods, but it doesn't
> wrap the rest (todo for kde5?)
> Note that I'm explaining the current situation (result of Waldo's initial
> hacking and Thiago's port to D-Bus), not saying that it couldn't have been
> done better for kde4 :-)

 I see. KDE3 had just QCString klauncher(), which returned "klauncher". I 
guess the problem results from an attempt to make it somewhat more 
sophisticated for KDE4 :).

> >  And more importantly, does somebody have any idea how to get rid of it?
> > Was that really meant to be public API?
> Yes, at least in kde3 and it stayed for kde4 and it has been used, so we
> can't get rid of it IMHO.
> >  The crash I was getting was because ksmserver normally builds its own
> > copy to access the klauncher interface
> If you fix the kdecore version to be autogenerated, then it will be
> uptodate and useable, and you won't need to build your own copy in
> ksmserver.
> >  Thinking of it, this generated code should be in anonymous namespace if
> > it is not guaranteed that it will stay binary compatible.
> Why wouldn't it stay binary compatible? It should... (unless the current
> version was generated by a too old version of dbusxml2cpp that did things
> too differently).

    inline QDBusReply<void> autoStart(int phase)
        QList<QVariant> argumentList;
        argumentList << qVariantFromValue(phase);
        return callWithArgumentList(QDBus::Block, QLatin1String("autoStart"), 

    inline QDBusPendingReply<> autoStart(int phase)
        QList<QVariant> argumentList;
        argumentList << qVariantFromValue(phase);
        return asyncCallWithArgumentList(QLatin1String("autoStart"), 

Hint: Return type. First one is from qdbusxml2cpp v0.6, the second v0.7. Since 
0.6 was part of e.g. Qt-4.2.2, this is apparently not supposed to produce 
something stable in time.

 Thiago: Can something like this happen again?

 But I guess that either way this leaves only the option of making ksmserver 
use the kdecore version and revisit this for KDE5.

Lubos Lunak
KDE developer
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz

More information about the kde-core-devel mailing list