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

[Alex Merry]

> 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.

Also,
connect(&service, SIGNAL(applicationStarted(QStringList)), &service, SIGNAL(activateRequested()))
is a single line of code.


- Alex


-----------------------------------------------------------
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/1b161e2d/attachment.html>