I love my spinny cube. I don't like it when my spinny cube doesn't spin. When the widget dashboard is open, desktop switching effects don't run when you switch desktops. I noticed this with the desktop cube enabled, and tested it with the sliding effect too. Reproducible: Always Steps to Reproduce: 1. Set a flashy kwin effect to desktop switching. 2. Open the widget dashboard. 3. Switch desktops. I used a keyboard shortcut, but any other means probably work too. Actual Results: Desktop switches fine, but without the special kwin effects that I love ever-so-much. The screen just changes to the windows on the next desktop. Expected Results: The spinning cube should spin. Or slide. Or fade. Or whatever you have your window switching effect set to. Bah, it's not that important. As far as edge-cases go, this is quite an obscure bug. Switching desktops doesn't change the dashboard, so I don't really see why anyone would do it. This would probably just be a bit of polish work.
Sorry, typo. The expected results line SHOULD read: The spinning cube should spin. Or slide. Or fade. Or whatever you have your desktop switching effect set to. Also, window switching effects still work fine when in the dashboard.
root cause is that it is possible to switch desktops while dashboard is active. Therefore setting as duplicate of this bug. The actual issue here is that the dashboard effect is a fullscreen effect which disables other fullscreen effects like the switch desktop animation. *** This bug has been marked as a duplicate of bug 159519 ***
Wait, but that bug is marked as closed. Does that mean it's fixed in git?
Looks like this bug describes what the workaround for the other bug has caused. Still source of the issue is that you can effectively process window management while the dashboard thing is up - as bug 159519 says ;-) (The bug is btw. not marked fixed but "works for me" by its reporter who meanwhile just happens to be the kwin maintainer. Real fix could eg. be to 1. block global shortcuts for the dashboard window (if it gets the focus, i've never used that thing) 2. or -as mentioned- have the dashboard grab input devices 3. or tag the dashboard window so that the WM can know that there should be no effective WM possible only option 2 is WM agnostic (as "dangerous" it is), option 1 can -if possible at all- be achieved by a KWin rule (kcmshell4 kwinrules)
(In reply to comment #4) > Real fix could eg. be to > 1. block global shortcuts for the dashboard window (if it gets the focus, > i've never used that thing) I think not possible, as there is one dashboard window per screen > 2. or -as mentioned- have the dashboard grab input devices also difficult due to the one dashboard per screen...
> (In reply to comment #4) > > Real fix could eg. be to > > 1. block global shortcuts for the dashboard window (if it gets the focus, > > i've never used that thing) > I think not possible, as there is one dashboard window per screen there's nothing preventing one from having a rule for all dashboard windows (as long as they're detectable) and while i don't know how and if focus is passed around dashboard it will have (and likely want anyway?) to use a local shortcut to do this (since it needs kbd focus anyway to get this rule effective) > > 2. or -as mentioned- have the dashboard grab input devices > also difficult due to the one dashboard per screen... -> internal focus / input management (the process still receives all input, whether it grabbed the pointer or not - the reason for our rmb ./. ffm issue) Is a popup kind of window type reasonable for that thing?
(In reply to comment #6) > Is a popup kind of window type reasonable for that thing? doubt it. It also opens additional (managed) windows when configuring e.g. a widget.