Bug 213847 - windows that are moved to another desktop should be treated as sticky windows
Summary: windows that are moved to another desktop should be treated as sticky windows
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: effects-various (show other bugs)
Version: unspecified
Platform: Archlinux Packages Linux
: NOR normal with 2 votes (vote)
Target Milestone: 4.11
Assignee: KWin default assignee
URL:
Keywords:
: 172432 338227 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-11-09 15:19 UTC by Hans Chen
Modified: 2018-06-01 06:51 UTC (History)
3 users (show)

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


Attachments

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