SUMMARY When using the icons only taskbar with grouped windows, the previews are very sensitive about the cursor leaving them for a moment either not being over any part of the taskbar or previews or touching other icons. I think it would improve the UX if the delay for switching to the previews of other programs would be higher. STEPS TO REPRODUCE 1. Hover an icon on the icons-only-taskbar until the previews of the grouped windows appear. 2. Move with the cursor through the previews, accidentally leave the previews and touch another icon in the taskbar. 3. The previews are almost instantly hidden and you need to move the cursor back to the icon of the program you wanted to switch to, wait for the previews to appear, and then carefully select the right window without the cursor leaving the previews even for a split second.
See also #469983 for another bug about previews changing too quickly - a delay in the right place might fix both.
Can you share more information of your system? System settings -> About this system -> click on "copy details" and paste it here. Thanks!
Setting as waitingforinfo
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This time the stupid bot is actually right and I should have already posed it ... here is the info that is still missing: Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.13 Graphics Platform: X11
This exact issue was supposed to be resolved with the implementation of a triangle mouse filter in Plasma 5.27 (which I see you have); see Bug 358930. Could you attach a screen recording that shows the exact problem you're encountering? Maybe the triangle filter is broken for you, for some reason. Thanks!
Can it be related to having a vertical panel? The graphic* linked in the other bug also seems to have the triangle the other way round than what my problem is, but maybe here it already flipped. It would be cool if there is any way to visualize the triangle. I'm not even sure how I would construct the triangle when moving from the preview to the taskbar as the taskbar items are no children of the previews and the amazon solution seems to work by assuming a hierarchy. * https://64.media.tumblr.com/53bdf2f4d5b0a7489743e2eaa140cd89/96541d7f363acfd3-e5/s500x750/8896d08ca510f3c71f98e61f729f8b82ea908614.png
Created attachment 172047 [details] Example Here is an example for a cursor path that closes the previews as soon as the terminal icon is touched.
Ok, I can reproduce the issue now. It seems that the triangle filter is not behaving properly. Sometimes it works, but most of the time it doesn't. I can reproduce this on vertical as well as horizontal panels. Maybe the region calculation is off.
Created attachment 172202 [details] A diagram of the triangle mouse filter as it works currently. Can reproduce. But right now the triangle mouse filter is designed for this path to happen, i.e. it prevents switching to another task while you're moving your mouse from the initial point to the opened tooltip, but the reverse where you move your mouse *towards* the task "from above" as it were is supposed to be an instant switch, so that people have a way to switch tasks once a tooltip is opened without needing to move their mouse through an invisible circuitous route. See attachment. We could add a delay, but then the entire point of all the complexity of the triangle filter in the first place was to avoid delays...
That diagram doesn't actually match what I'm seeing: a movement that's within the triangular "don't activate" zone is switching to thumbnails of a different task when the cursor passes over their icon.
(In reply to Nate Graham from comment #11) > That diagram doesn't actually match what I'm seeing: a movement that's > within the triangular "don't activate" zone is switching to thumbnails of a > different task when the cursor passes over their icon. I drew it a little bit far in the diagram, but the point is that if you move the mouse so that it enters another task "from above", it is designed to cause a switch even if the mouse lands in an area that would have been blocked by the filter otherwise. The intent is fast switching, so you can just dip your cursor from a tooltip into another task to switch instantly, but spurious moves in the task to tooltip direction are still filtered.
No, it enters the other task from the side, not from above.
(In reply to Nate Graham from comment #13) > No, it enters the other task from the side, not from above. "From above" is used in the sense of "from the direction where tooltips are"
That's correct. I know you know I use a vertical panel, but I was using terminology relevant to a horizontal panel, which the diagram depicted.
Maybe we're not talking about the same behavior then. Could you add a screen recording?
Created attachment 172376 [details] Screen recording Sure, here you go.
Got it, can reproduce. That's an issue. It seems to be based on where the cursor is when the tooltip opens, since the triangle filter starts from the point where the mouse was at the time of tooltip opening. I thought I put in enough mitigations against this through the secondary point calculation, but apparently not... I'll look into it when I get time. But I'm not sure this is the same issue Alex is reporting. They're different mechanisms. Alex's issue as far as I can tell is about what happens when, once you've exited the filter area into the tooltip, what happens when your cursor happens to graze another task.
I think my problem is not covered by the current filter even when working correctly, if I understand the filter the right way. Currently it avoids, if I understand it correctly, that moving from an application icon to a preview switches to previews of another application when the mouse crosses the other applications's icon, e.g, a triangle with the apex at the launcher icon. Once the mouse moves over the previews, there should probably be a new (or second) triangle with the apex at the preview and not at the launcher icon protecting the path along the axis of the previews. I am not even sure if it should be a triangle, because it would probably need to be something that moves along with the cursor (why should the first preview stay the reference point?) and then I wonder if a triangle would even be the correct shape for that.