Review Request 128473: Avoid recursive calls to QPlatformTheme::createPlatformSystemTrayIcon()

David Edmundson david at davidedmundson.co.uk
Tue Jul 19 15:06:20 UTC 2016



> On July 18, 2016, 5:49 a.m., Martin Gräßlin wrote:
> > I acknowledge the problem in general, but I think the solution is wrong as this creates now a race condition on startup where apps don't show up in the systray at all. That is if an application tries to create a systray icon before Plasma is started.
> 
> Martin Tobias Holmedahl Sandsmark wrote:
>     it still creates a systray icon, it just creates an "old style" tray icon.
> 
> Martin Gräßlin wrote:
>     > it still creates a systray icon, it just creates an "old style" tray icon.
>     
>     Which won't work on Wayland. And yes that's a valid point as we need to think further than 3 months ;-)
> 
> Martin Gräßlin wrote:
>     actually it won't even work on X11 as if Plasma is not up yet, neither will be the xembed proxy. Which means no systray and Qt won't create it.
> 
> Martin Tobias Holmedahl Sandsmark wrote:
>     won't it jump into the xembed proxy when it appears? I seem to recall that happening, but I might be wrong.
> 
> Martin Tobias Holmedahl Sandsmark wrote:
>     and regarding wayland, what does the "normal" platform plugin for wayland do with QPlatformSystemTrayIcon?
> 
> Martin Tobias Holmedahl Sandsmark wrote:
>     well, I looked in qtbase, and apparently Qt has a SNI implementation, so the fallback here should work under wayland?
> 
> David Edmundson wrote:
>     The Qt SNI won't work.
>     
>     That's in QGenericUnixTheme - however because we load our platform theme (which subclasses QPlatformTheme) we don't load it - and it's private API so can't (without changing Qt)
> 
> Martin Tobias Holmedahl Sandsmark wrote:
>     Anyhow, you don't agree that it is better for the application to not get a tray icon than recursing like this and not showing up at all and spinning like crazy?

I do agree. But it's also important to base patches based on the right assumptions.

Which is why in the other comment thread I simply want to understand why the current solution doesn't work and how you end up in this situation where this is a problem before merging.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128473/#review97514
-----------------------------------------------------------


On July 17, 2016, 8:14 p.m., Martin Tobias Holmedahl Sandsmark wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128473/
> -----------------------------------------------------------
> 
> (Updated July 17, 2016, 8:14 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-integration
> 
> 
> Description
> -------
> 
> If the status notifier item host is not available, KSNI tries to create a normal QSystemTrayIcon.
> 
> The plasma platform plugin uses KSNI when it is called to create a QPlatformSystemTrayIcon.
> 
> So if the status notifier item host for any reason was unavailable, this would recursively run forever (assuming a turing machine with infinite memory).
> 
> 
> Diffs
> -----
> 
>   src/platformtheme/kdeplatformsystemtrayicon.h 6825b4d 
>   src/platformtheme/kdeplatformsystemtrayicon.cpp 0e82385 
>   src/platformtheme/kdeplatformtheme.cpp 5f0407c 
> 
> Diff: https://git.reviewboard.kde.org/r/128473/diff/
> 
> 
> Testing
> -------
> 
> Now it is possible to run applications that have tray icons with the plasma platform plugin even when the status notifier item host is down or unavailable.
> 
> 
> Thanks,
> 
> Martin Tobias Holmedahl Sandsmark
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160719/64f1d61d/attachment-0001.html>


More information about the Plasma-devel mailing list