> On Nov. 13, 2013, 1:33 p.m., David Faure wrote: > > tier1/kdbusaddons/src/CMakeLists.txt, line 17 > > <http://git.reviewboard.kde.org/r/113830/diff/1/?file=213290#file213290line17> > > > > Maybe this should be called org.kde.KDBusService.xml instead. > > > > It's an implementation detail of KDBusService. > > > > Application makes one think of KApplication/QApplication...
> 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). 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. > 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. 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 ----------------------------------------------------------- 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
