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

[David Faure]

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



tier1/kdbusaddons/src/CMakeLists.txt
<http://git.reviewboard.kde.org/r/113830/#comment31321>

    Maybe this should be called org.kde.KDBusService.xml instead.
    
    It's an implementation detail of KDBusService.
    
    Application makes one think of KApplication/QApplication...



tier1/kdbusaddons/src/kdbusservice.h
<http://git.reviewboard.kde.org/r/113830/#comment31322>

    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.



tier1/kdbusaddons/src/kdbusservice.h
<http://git.reviewboard.kde.org/r/113830/#comment31319>

    the the -> the



tier1/kdbusaddons/src/kdbusservice.cpp
<http://git.reviewboard.kde.org/r/113830/#comment31320>

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


- David Faure


On Nov. 13, 2013, 12:39 a.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, 12:39 a.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/src/org.kde.Application.xml PRE-CREATION 
>   tier1/kdbusaddons/src/org.freedesktop.Application.xml 16934e24ca99da68222be9f728239b1fb0786f72 
>   tier1/kdbusaddons/src/kdbusservice.cpp b773c80b30c6ee39d6d8b4d8c962b83dbd87f7d4 
>   tier1/kdbusaddons/src/kdbusservice.h bf79e227209510246d0ec5ff1d5277e6083c4a1a 
>   tier1/kdbusaddons/src/CMakeLists.txt 0509015afd2d24d34f85a7d6fd786092820814bf 
>   tier1/kdbusaddons/autotests/kdbusservicetest.cpp 5eecb5e834bddc177539f5eedb51a77a276d7899 
> 
> 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/fea46f39/attachment-0001.html>