> On Nov. 11, 2013, 5:45 p.m., David Faure wrote: > > Thanks for implementing that. Indeed the TODO didn't mean adding a method > > to QApplication, but it was about the member that was there in qt4, and > > that is now in QXcbConnection. > > > > The optional dependency on QtGui breaks the rules for tier1 addons, though. > > Maybe we need to move KDBusService up to... the KService framework maybe? > > > > (Note that there are more todos about startupId stuff, in > > KDBusService::Activate etc. This would probably be easier to implement in a > > higher framework too. > > Alex Merry wrote: > Oh? I can't find a rule on the wiki that precludes it. > > Regardless, the other TODOs would be a lot easier from tier2 or above, > where we could use KStartupInfo from KWindowSystem. KService probably does > make the most sense out of what we have, although it's still a bit mismatched > (I wouldn't expect to need KService if my application didn't use plugins). > Is there maybe a use for a framework that provides things to help make apps > behave well in free desktop environments? > > Kevin Ottens wrote: > I would still prefer having KDBusService stay there... What about doing > the xcb connection dance in our platform theme plugin instead? And then > attaching a dynamic property on the qapp instance? > > This way we can channel the startup id, and from KDBusService POV it only > needs to know about QCoreApplication. > > Alex Merry wrote: > How about this for an idea: platform_data is an inherently platformy > thing (as its name suggests). Perhaps KDBusService could have a > (global-static-ish) way of registering a platform interface that contained > virtual methods > QVariantMap platformData() const; > void activated(QVariantMap platform_data); > (as a minimum; more fine-grained hooks could also be provided) that the > platform plugin could implement and register. The constructor would use the > first method to get the necessary data (such as sn id) at one end, and the > second to use it in the main instance (and when called via D-Bus).
Doesn't make a big difference with what I'm proposing at the end of the day... I'd say I still prefer the dynamic property, less coupling and less symbols exported (even though it's more fragile or error prone, but it won't be touched often). - Kevin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113798/#review43449 ----------------------------------------------------------- On Nov. 11, 2013, 4:37 p.m., Alex Merry wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113798/ > ----------------------------------------------------------- > > (Updated Nov. 11, 2013, 4:37 p.m.) > > > Review request for KDE Frameworks, David Faure and Kevin Ottens. > > > Repository: kdelibs > > > Description > ------- > > KDBusService: pass the desktop startup ID when calling Activate > > We use a bit of private API to ask the xcb platform plugin for it > directly. > > The TODO in the original code suggested getting a method in QApplication (or > one of its ancestors) to get the startup id, but I think that's very unlikely > to be accepted. > > There's still the hooks to make use of the value on the other side to sort > out, though. > > > Diffs > ----- > > tier1/kdbusaddons/CMakeLists.txt 78cc44333574355ff8504481fcb9c88cfc90daf5 > tier1/kdbusaddons/src/CMakeLists.txt > 0509015afd2d24d34f85a7d6fd786092820814bf > tier1/kdbusaddons/src/config-kdbusaddons.h.cmake PRE-CREATION > tier1/kdbusaddons/src/kdbusservice.cpp > b773c80b30c6ee39d6d8b4d8c962b83dbd87f7d4 > > Diff: http://git.reviewboard.kde.org/r/113798/diff/ > > > Testing > ------- > > Builds, tests pass. A quick-hack modification of the autotest, along with > some hacked-in debug statements, show the value is getting passed properly. > > > Thanks, > > Alex Merry > >
_______________________________________________ Kde-frameworks-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
