Bug 314715 - After Present Windows Effect is initialized, the active Window scales bigger abruptly
Summary: After Present Windows Effect is initialized, the active Window scales bigger ...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-window-management (show other bugs)
Version: 4.10.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/111...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-08 21:19 UTC by Björn Sonnenschein
Modified: 2013-07-01 19:19 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.11
thomas.luebking: ReviewRequest+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Sonnenschein 2013-02-08 21:19:45 UTC
In the present windows effect the highlighted window is bigger than other and as soon as the mouse hovers over another window, that window will smoothly become bigger.

But when the present windows effect is started, while the windows are aligned in grid the active window is as small as all other windows and jumps up to "active-window" size then.

Reproducible: Always

Steps to Reproduce:
1. Open some windows.
2. Start the present windows effect and observe the behavior of the active window.
Actual Results:  
The active window has the size of inactive windows during present windows initialisation and then jumps to a bigger size

Expected Results:  
the active window should be scaled to it's final size smootly during the transition.

Linux mint 14, 64bit, kde from backports.
Comment 1 Thomas Lübking 2013-02-08 22:13:34 UTC
Yes, part of commit f448a4e48ed7de2f65b041569b93f5de9ae51c55 to fix bug #294428.

We could try to prevent only clamping but allow zooming, but that will cause other artifacts ...
Comment 2 Björn Sonnenschein 2013-02-09 12:47:32 UTC
I have no Idea how the effect works (will look through the code next days), but isn't it possible to detect the active window and scale it it's final size during the animation and so don't scale it to the size of inactive windows at first?
Comment 3 Thomas Lübking 2013-02-09 13:08:34 UTC
It's not only size but final geometry and that was the behavior causing bug #294428

The effect needs a rewrite on top of the AnimationEffect class(pot. on ECMA) or QML.

This would also cover what you likely observe in bug #314717 (the way the motionmanager determines geometry. With maximized windows i can indeed see a "snap" into the final position)
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 314840, 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