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).
src/src/kdelibs/kdecore/util/klauncher_iface.h:
inline QDBusReply<void> autoStart(int phase)
{
QList<QVariant> argumentList;
argumentList << qVariantFromValue(phase);
return callWithArgumentList(QDBus::Block, QLatin1String("autoStart"),
argumentList);
}
build/kdebase/workspace/ksmserver/klauncher_interface.h:
inline QDBusPendingReply<> autoStart(int phase)
{
QList<QVariant> argumentList;
argumentList << qVariantFromValue(phase);
return asyncCallWithArgumentList(QLatin1String("autoStart"),
argumentList);
}
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