| Summary: | Widget dashboard disables desktop switching effects. | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | David Yang <davidyang6us> |
| Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Chakra | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
David Yang
2012-04-30 09:49:21 UTC
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. |