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