Feedback on KDBusService::activateRequested

[David Narvaez]

Hi,

After working on the implementation of the unique mode in Rekonq[0], I
have some (unsolicited) feedback about the activateRequested slot that
I would like to share in case these issues can be addressed:

Whenever I use libraries that deal with command line arguments my
first question is whether they expect the first argument to be the
name of the executable or not. For KDBusServices, it turns out that
the answer is "it depends", and I think that is almost never a good
answer. For some context, the current behavior[1] is:

- line 119: If the executable was called with more than one argument,
send them all to the instance already running through a call to the
CommandLine signal.
- line 126: If the executable was called with just one argument (the
executable name) call the Activate signal of the instance already
running (effectively sending an empty list of arguments).

At the other end, the receiver (which we can assume is using
QCommandLineParser because this is Qt5 etc) always has to deal with
the two cases because QCLP requires at least one argument and will
crash if you pass an empty list of arguments. IMO, whenever all
applications need to write the same  boilerplate code - in this case
if(arguments.size() > 0) - that is already an indication of a bad API
(see, e.g., [2]).

In addition to that, one can argue that some info is lost: suppose you
have a binary and several symlinks to that binary, and this binary
decides what to do depending on the symlink used to call it (think of
busybox). If this application was using KDBusService to implement
Unique mode, then it would no longer know what the caller binary was.

So my question woud be: is this behavior mandated by some standard? or
can it be modified to always call CommandLine with the list of
arguments?

Thanks.

David E. Narvaez

[0] https://git.reviewboard.kde.org/r/120794/
[1] http://quickgit.kde.org/?p=kdbusaddons.git&a=blob&h=ea772&hb=d8ff8&f=src%2Fkdbusservice.cpp
[2] http://lxr.kde.org/source/kde/workspace/plasma-workspace/plasma-windowed/plasmawindowedcorona.cpp?v=kf5-qt5#0103