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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel