Bug 213847

Summary:	windows that are moved to another desktop should be treated as sticky windows
Product:	[Plasma] kwin	Reporter:	Hans Chen <hanswchen>
Component:	effects-various	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	kde, tarasov.igor, vlad.zahorodnii
Priority:	NOR	Flags:	thomas.luebking: ReviewRequest+
Version:	unspecified
Target Milestone:	4.11
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Hans Chen 2009-11-09 15:19:32 UTC

Version:            (using KDE 4.3.3)
OS:                Linux
Installed from:    Archlinux Packages

To reproduce:
1. Set "Effect for desktop switching" to "Slide"
2. Set "Titlebar wheel event" (in "Actions") to "Move to Previous/Next Desktop"
3. Scroll up/down on a window titlebar

It looks like the window disappears, and then slides in with the new virtual desktop. I think it would look better if the window stayed in the same place, with the other windows sliding out/in.

Comment 1 Hans Chen 2009-11-09 15:21:17 UTC

Seems like the Desktop Cube Animation has the same problem. Should I file a bug for it as well?

Comment 2 Martin Flöser 2009-12-06 19:45:55 UTC

*** Bug 172432 has been marked as a duplicate of this bug. ***

Comment 3 Martin Flöser 2010-06-12 12:40:00 UTC


*** This bug has been marked as a duplicate of bug 185710 ***

Comment 4 Thomas Lübking 2011-11-13 15:54:17 UTC

This is *not* a dupe of bug #185710 but essentially says

"effects: windows that are moved to another desktop should be treated as sticky windows"

could require an API extension, i've blocked moving windows in the generic effects plugin (so far not released version), but that doesn't cover scrolling.
will have a look for the effect =)

Comment 5 Thomas Lübking 2012-05-02 19:27:49 UTC

http://git.reviewboard.kde.org/r/104825/

Comment 6 Thomas Lübking 2012-05-03 21:00:57 UTC

Git commit 695fb69aded515a6f557fc5a08c39ac753f08025 by Thomas Lübking.
Committed on 02/05/2012 at 21:16.
Pushed by luebking into branch 'master'.

add desktopChanged signal to effects that carries the optionally changing widget
FIXED-IN: 4.9

M  +4    -2    kwin/effects.cpp
M  +1    -1    kwin/effects.h
M  +7    -1    kwin/libkwineffects/kwineffects.h
M  +1    -1    kwin/scripting/workspace_wrapper.cpp
M  +1    -1    kwin/scripting/workspace_wrapper.h
M  +1    -1    kwin/workspace.cpp
M  +1    -1    kwin/workspace.h

http://commits.kde.org/kde-workspace/695fb69aded515a6f557fc5a08c39ac753f08025

Comment 7 Igor Tarasov 2014-08-13 06:33:33 UTC

*** Bug 338227 has been marked as a duplicate of this bug. ***

Comment 8 Igor Tarasov 2014-08-13 06:49:26 UTC

Still exists in KDE 4.13.3.

Animations in KDE: http://www.youtube.com/watch?v=iDHsHoOiPqs
And to compare in Compiz: http://www.youtube.com/watch?v=gVTppLvXnUc#t=271
Also, in Android dragging widget across desktops animation works the same way as in compiz.

In compiz and android animation makes you easily understand what happens - window is being moved from one workspace to the other. KDE animation is counter-intuitive - as window disappears first, and then moves in.

Comment 9 Thomas Lübking 2014-08-13 07:29:14 UTC

stock effect will unlikely change for kde4

http://sourceforge.net/projects/bekwinfx/

operates as you expect on virtual desktop animations (if that helps you)

Comment 10 Vlad Zahorodnii 2018-06-01 06:51:08 UTC

https://phabricator.kde.org/D9487 fixed this bug.

Also, FWIW, "the new" slide effect doesn't have such problems. (https://phabricator.kde.org/D9638)