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