Review Request 113830: Allow unique apps to access command-line arguments of later invocations

[David Faure]

> On Nov. 13, 2013, 1:33 p.m., David Faure wrote:
> > tier1/kdbusaddons/src/kdbusservice.h, line 172
> > <http://git.reviewboard.kde.org/r/113830/diff/1/?file=213291#file213291line172>
> >
> >     When is this emitted, then? Only if the dbus-based app launcher calls Activate?
> >     
> >     Maybe launching the app with no cmdline arguments should call Activate instead of CommandLine, to keep things simple for apps that don't take cmdline args?
> >     Launching the app with no args really does mean "activate".
> >     
> >     For apps that do handle cmdline args, they'll need to implement both anyway, whichever solution we choose, in order to follow the spec.
> >     
> >     So actually that's another reason for calling Activate if no args: otherwise app developers won't see the point in implementing activateRequested, since in their tests it will never be called, only the gnome app launcher (and one day the kde app launcher, presumably) calls that.
> >     
> >     Overall, I'm not sure what's the best solution, I'm open to suggestions.
> 
> Alex Merry wrote:
>     I see your point, but at the same time, it makes less logical sense that way.  Besides which, the activation stuff requires setting stuff in the desktop file anyway, so the application developer has to at least put *some* thought into it.
>     
>     Perhaps a flag?  Say, DiscardCommandLineArguments or something, that basically says "I don't deal with command-line arguments, so use activateRequested instead of applicationExecuted"?
> 
> Alex Merry wrote:
>     Another option is to just merge the activateRequested() and applicationStarted(QStringList) signals into a single activateRequested(QStringList) signal that is passed an empty list if it is triggered by the D-Bus Activate call.
>     
>     This still leaves the fact that it will have to deal with the command-line equivalents of the Open and ActivateAction D-Bus calls, so I feel it is a conceptually inferior option, even if it typically allows slightly less application code.
> 
> Alex Merry wrote:
>     Also,
>     connect(&service, SIGNAL(applicationStarted(QStringList)), &service, SIGNAL(activateRequested()))
>     is a single line of code.

I like the idea of activateRequested(QStringList).

It's also closer to our current kde4 code (MyUniqueApplication::newInstance(), which then calls KCmdLineArgs::parsedArgs() to parse the args).

It makes me wonder why the spec doesn't just have that, then... well I because it was written with gui app launchers in mind, the command-line case is an additional feature.

Apps have to deal with the command-line equivalent of Open in any case - which is usually "passing urls on the command line", I don't see how merging two signals changes that. Same for actions (e.g. kmail --compose).

All of this is exactly what newInstance() currently deals with, and what apps would have to do in their slotActivateRequested().


> On Nov. 13, 2013, 1:33 p.m., David Faure wrote:
> > tier1/kdbusaddons/src/kdbusservice.cpp, line 185
> > <http://git.reviewboard.kde.org/r/113830/diff/1/?file=213292#file213292line185>
> >
> >     Hmm, the problem with a signal is that we can't get a return value, to return something on errors (e.g. invalid argument) rather than 0....
> >     
> >     It seems to me that we need an interface (in the C++ sense) that an object in the app would inherit from, with a virtual method int handleCommandLine(...). The app would set the instance of that interface in the KDBusService.
> >     
> >     Or just deriving from KDBusService, but I think a separate interface is cleaner - at least, too many years of virtuals in QApplication itself have shown various problems (too much of a monolithic design, for some apps).
> 
> Alex Merry wrote:
>     The other possibility I thought of was a "setExitValue" (or some similar name) method in KDBusService that the slot could call if it wanted to.  Which is more ugly, but possibly easier on the application implentations.

True. This might be good enough.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113830/#review43586
-----------------------------------------------------------


On Nov. 13, 2013, 1:52 p.m., Alex Merry wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113830/
> -----------------------------------------------------------
> 
> (Updated Nov. 13, 2013, 1:52 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> -------
> 
> Allow unique apps to access command-line arguments of later invocations
> 
> 
> Diffs
> -----
> 
>   tier1/kdbusaddons/autotests/kdbusservicetest.cpp 5eecb5e 
>   tier1/kdbusaddons/src/CMakeLists.txt 0509015 
>   tier1/kdbusaddons/src/kdbusservice.h bf79e22 
>   tier1/kdbusaddons/src/kdbusservice.cpp b773c80 
>   tier1/kdbusaddons/src/org.freedesktop.Application.xml 16934e2 
>   tier1/kdbusaddons/src/org.kde.KDBusService.xml PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/113830/diff/
> 
> 
> Testing
> -------
> 
> Builds, test passes.
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131113/c969f10d/attachment-0001.html>