Bug 314840

Summary:	present windows: stacking problems
Product:	[Plasma] kwin	Reporter:	Franz Trischberger <franz.trischberger>
Component:	effects-window-management	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	Flags:	thomas.luebking: ReviewRequest+
Priority:	NOR
Version:	4.10.0
Target Milestone:	---
Platform:	Other
OS:	Linux
URL:	https://git.reviewboard.kde.org/r/111276/
Latest Commit:	http://commits.kde.org/kde-workspace/d2d71aaa4f5fa18e79757712def78cb4d4314345	Version Fixed In:	4.11
Sentry Crash Report:

Description Franz Trischberger 2013-02-10 18:29:26 UTC

There are 2 problems I realized:

1) activation with screen edge:
* Open two windows, best would be if they had strong contrasts
* Place them in the edge where your "present windows" point is located (top left for me
* move the mouse there, you will see a slight flickering - the top window moves away and the bottom one seems to get focus. (naive observation by a noob ;))

2) In the present wondows view:
It might happen that windows are placed/sized that they can overlap each other when hovered. In that case it happens that when you a window lower in the stack it gets above the other, when you leave it it immediately stacks under the other window before it gets resized again.

If you don't notice those things you might want to set animation speed to <=very slow.

Reproducible: Always

Comment 1 Thomas Lübking 2013-02-10 18:56:15 UTC

I can reproduce the second one and it's kind of "expectable" since the selected window gets raised unconditionally and immediately.
Should maybe happen after 50% of the time, but it's a remote issue.

Reg. item no. 1 - i didn't even understand what to look for ;-)
If i move the cursor to the PW activation edge, the effect kicks in and all windows start moving.

Does it "move" away in the z-order or x/y? Is that during the PW animation?

Comment 2 Franz Trischberger 2013-02-10 19:23:01 UTC

Top left corner starts PW. I do not have a panel in tat edge, so the mouse is over the deco.
Open e.g. kwrite (usually quite "white") place it in the top left corner.
Open gwenview (usually quite "dark"), also place it in the top left corner, above kwrite.

Now move the mouse into the left corner - it is over both windows now.

When PW anmiation starts the kwrite window comes above the gwenview window, goes back again. The slower the animation speed is set the more often this may happen, resulting in "flickering" (as it happens really fast ;))

recordMyDesktop seems to occupy the edges, so I can't trigger it. Do you know an alternative that works?

Comment 3 Thomas Lübking 2013-02-10 19:33:22 UTC

No necessary, same issue.
The window under the mouse gets elevated and both are (causing a selection conflict)

Together with bug #314715 (and from there #294428) this sounds as if we maybe should prevent window selection for the first half of animate-in and second half of animate-out but then allow with zoom.

For in-effect elevation, see above.

Comment 4 Thomas Lübking 2013-07-01 19:19:40 UTC

Git commit d2d71aaa4f5fa18e79757712def78cb4d4314345 by Thomas Lübking.
Committed on 27/06/2013 at 19:54.
Pushed by luebking into branch 'master'.

Don't highlight hoverd window while PW start/stops

Instead have a synthetic motion after the effect started
and explicitly set the selected window on click/drags
Related: bug 314715, bug 314717
FIXED-IN: 4.11
REVIEW: 111276

M  +16   -3    kwin/effects/presentwindows/presentwindows.cpp
M  +1    -0    kwin/effects/presentwindows/presentwindows.h

http://commits.kde.org/kde-workspace/d2d71aaa4f5fa18e79757712def78cb4d4314345