Bug 314840 - present windows: stacking problems
Summary: present windows: stacking problems
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-window-management (show other bugs)
Version: 4.10.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/111...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-10 18:29 UTC by Franz Trischberger
Modified: 2013-07-01 19:19 UTC (History)
0 users

See Also:
Latest Commit: http://commits.kde.org/kde-workspace/d2d71aaa4f5fa18e79757712def78cb4d4314345
Version Fixed In: 4.11
thomas.luebking: ReviewRequest+

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
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