Bug 314715

Summary:	After Present Windows Effect is initialized, the active Window scales bigger abruptly
Product:	[Plasma] kwin	Reporter:	Björn Sonnenschein <green>
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:	Ubuntu
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 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