Review Request 113798: KDBusService: pass the desktop startup ID when calling Activate

[Kevin Ottens]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131115/39dfcd21/attachment.html>