Bug 299095

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:

Description David Yang 2012-04-30 09:49:21 UTC

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.

Comment 1 David Yang 2012-04-30 09:52: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.

Comment 2 Martin Flöser 2012-05-06 18:49:33 UTC

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 ***

Comment 3 David Yang 2012-05-06 22:54:21 UTC

Wait, but that bug is marked as closed. Does that mean it's fixed in git?

Comment 4 Thomas Lübking 2012-05-07 12:39:25 UTC

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)

Comment 5 Martin Flöser 2012-05-07 15:36:15 UTC

(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...

Comment 6 Thomas Lübking 2012-05-07 17:06:32 UTC

> (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?

Comment 7 Martin Flöser 2012-05-07 17:27:46 UTC

(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.