Bug 213847

Summary: windows that are moved to another desktop should be treated as sticky windows
Product: kwin Reporter: Hans Chen <hanswchen>
Component: effects-variousAssignee: 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: Archlinux Packages   
OS: Linux   
Latest Commit: Version Fixed In:

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)