Created attachment 89999 [details]
Picture of problem

This has been filed before but I can't find it. Martin, can you reassign?

(In reply to Eike Hein from comment #2)
> This has been filed before but I can't find it. Martin, can you reassign?

reassign to what? That's a problem in plasmashell: it should add the tooltip to the highlight window group.

Didn't the effect ignore transients of the controller window in the past, though?

(In reply to Eike Hein from comment #4)
> Didn't the effect ignore transients of the controller window in the past,
> though?

no - also the highlight windows effect didn't change.

Git commit a9360e7159d01a5ebff54be02de2493620702511 by Eike Hein.
Committed on 16/12/2014 at 18:38.
Pushed by hein into branch 'master'.

Add tooltip window to the list of highlighted windows.

M  +1    -0    applets/taskmanager/package/contents/ui/main.qml
M  +23   -1    applets/taskmanager/plugin/backend.cpp
M  +6    -0    applets/taskmanager/plugin/backend.h

http://commits.kde.org/plasma-desktop/a9360e7159d01a5ebff54be02de2493620702511

If you mouse over the tooltip, it no longer hides, but mousing over the icon in the panel still hides the tooltip.

IMHO the effect should ignore transients of the controller window. I don't think that all the scaffolding for re-requesting the effect with a new window list makes for nice code, and I wouldn't be surprised if it was going to interact badly with the fade-in too. Martin, thoughts?

I fear that this can result in situations where windows get highlighted which are not supposed to be highlighted.

Here's the thing, though: To do this from the Plasma side, I have to figure out the window id of the parent window of the tooltip delegate item. Then I have to figure out when Plasma decides to show it. Then I have to merge it with the list of windows I really mean to highlight, and re-request the effect. This is doable (I've partly just done it above), but it's awkward to write because the Plasma API intentionally hides these from users as implementation details. For this other case, without doing it I'm also not entirely sure I can have it race-free (probably only after the tooltip window has already been shown()). Meanwhile, I the kwin effect system has an API built around the idea of "there's a new window, let me figure out if I care", doing it necessarily at the right times, ... it just seems a lot more obviously natural to handle this in kwin. I also suspect kwin might have an easier time doing the right thing on "I'm fading a new window into this situation" when it is the driver of everything, but who knows.

Maybe the effect API could have a "always highlight children of controller" flag ...?

doing that in the effect is also not that trivial: the effect needs to start tracking transients. That means: listening to all property changes (transient change is not available in the kwineffects API). Reading properties from the effects is awkward - we get it only as a QByteArray which needs to be casted to the right type. Using xcb directly is out of bounds - we try to reduce the dependency on the windowing system from the effects.

Getting this right in the effect sounds very complex to me - there are just too many states influencing it. To me from the WM perspective it looks like the client has all available information - and it used to work fine in KDE 4 times. Granted QtQuick sucks when it comes to windowing interaction (note: I do not trust that the tooltips have proper transient hints - that's something I would consider surprising if they are correct). Nevertheless I think the client has better possibilities to do the right thing.

KWin5 hides Plasma 4 tooltips too, so it seems unlikely that the problem is a change in Plasma.

Git commit 5ccfecdecb649f80e53f6f18abaa185a4886313d by Eike Hein.
Committed on 20/12/2014 at 18:02.
Pushed by hein into branch 'master'.

Fix tooltip bring faded out when shown during window highlight.

M  +40   -16   applets/taskmanager/plugin/backend.cpp
M  +5    -0    applets/taskmanager/plugin/backend.h

http://commits.kde.org/plasma-desktop/5ccfecdecb649f80e53f6f18abaa185a4886313d

I can confirm that the above commit fixed the issue. However, the tooltip seems to flash whenever you move your cursor from the panel to the window preview. It flickers by disappearing and reappearing very quickly. Doesn't affect the functionality though.

I have no explanation for that from the plasmashell side, so it might be kwin.

I also can't right click the icon of launched applications when highlight windows is enabled. Which means I cannot launch more than one of that application.

As an added note: There were additional commits past 5ccfecdec, so please make sure you test the branch tip instead of cherry-picking - though it won't affect this flickering issue, since the behavior of when the toolkit is shown/hidden hasn't changed in any of them. The only change here is when/what window ids kwin is told about to highlight. I suspect the flickering problem is in kwin incorrectly tweening between those states.

> I also can't right click the icon of launched applications when highlight windows is enabled. Which means I cannot launch more than one of that application.

Mouse handling hasn't changed in these commits. Is this a new regression?

Sorry, didn't mean to sound like I was cherry picking the commits. I build plasma-desktop from git, I assume I have all commits up to the point I pulled from git.

I can't reproduce any problems with right-clicking task buttons on my system, with any combination of window highlighting and tooltips enabled/disabled. Note that certain versions of Qt 5.x have bugs with mouse grabbing for popup menus that can cause the panel to appear non-responsive until you left-click somewhere on it once. If you can't rule that out, and it appears the problem is caused by a recent commit, please try to find the one that introduced it (e.g. by using git bisect).

Yeah, it seems like the Qt bug you mentioned. I have the issue that the panel becomes non-responsive. I also checked past builds of plasma-desktop and they all have this same issue, so it's not a regression, I must not have noticed the problem.

Sucks, but at least it means this ticket doesn't get more complicated for now :).

As for the flickering, I'm seeing it too. It doesn't happen with highlighting disabled, though, and enabling highlighting doesn't change the tooltip management in any way, it only starts telling kwin about windows to highlight including the tooltip. So I do think this moves the ball into kwin's court for now.

I'll reopen the ticket so it doesn't get forgotten, but will leave reassigning it to Martin after his assessment.

Martin is on vacation now I believe, and I'm gone now too, until Jan 5th - then we can pick this up again and hopefully address it in time for 5.2 getting tagged.

Thanks for the help, I'm amazed by how fast this was fixed.

KWin side now handled via bug 341934.

it appears that the popup menu for choosing among grouped windows suffers from the same problem (kwin 5.7.0, plasma 5.6.5 (debian being funny)).