Bug 185710 - wrong direction in "slide" plugin
Summary: wrong direction in "slide" plugin
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: unspecified
Platform: Compiled Sources Unspecified
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
: 192870 199430 313255 (view as bug list)
Depends on:
Reported: 2009-02-27 14:32 UTC by Tobias
Modified: 2023-03-02 23:48 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.25

attachment-32744-0.html (1.05 KB, text/html)
2022-03-16 21:34 UTC, Roey Katz

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias 2009-02-27 14:32:10 UTC
Version:            (using Devel)
Installed from:    Compiled sources

With a 4 virtual desktops layout (2 at top, 2 at bottom) and the slide plugin enabled, windows slide in the wrong direction when dragging a window to a desktop above.

When dragging the window to the desktop below, the other windows slide out of the top of the screen as expected. Similarly, when dragging it to the right they slide out of the left of the screen and when dragging it to the left, out of the right of the screen.

However, when dragging a window to the desktop above, the other windows slide out of the top of the screen, giving a wrong movement.
Comment 1 Martin Flöser 2009-05-16 13:55:34 UTC
*** Bug 192870 has been marked as a duplicate of this bug. ***
Comment 2 Jeremy Kerr 2009-06-19 03:58:47 UTC
I see the same bug here (Ubuntu Jaunty, KDE 4.2.2).

I have five virtual desktops. If I use the 'desktop grid' effect (which zooms out to show all desktops), I see that they're laid out in 1 row * 5 column grid:

 1 2 3 4 5

However, if I switch between virtual desktops, the slide effect will slide the windows as if the desktop is laid out in a 2 row * 3 column grid:

 1 2 3
 4 5

ie, if i switch from desktop 1 to desktop 4, the slide effect scans downwards, not sideways as expected.

Note that I do *not* have the pager plasmoid running. If I start the pager plasmoid, then the behaviour of the slide effect seems to be correct (laid out in a 1 * 5 grid). If I then remove the pager, the correct behaviour remains.

So, the workaround is to add the pager app and then immediately remove it, but this must be done on every login.
Comment 3 Tobias 2009-06-19 08:24:05 UTC
Jeremy, while I think, your bug is connected, I don't think it is exactly the same since you can repair it by adding the pager. The bug I was reporting is that really the slide should behave differently depending on if the switch occurs from the pager or from dragging windows.

In a

1 2
3 4

layout, when I'm on desktop 1 and click on desktop 2 on the pager, it's perfectly ok, if the windows slide out of the left side of the window (which looks like a 1->2 transition). The same goes for the case if I drag a window out of the right side of the desktop (again a 1->2 transition). However, if I drag it out the left side of the window, it really is a 2<-1 transition (since we're on a torus), and the other windows should slide out the right side of the window.

So the solution for this would be to either tell the slide plugin not only the source and destination desktop but also the direction of the transition or to disable "torus desktop switching" (i.e. 2<-1, 2->1, ... transitions).
Comment 4 Jeremy Kerr 2009-06-19 11:55:41 UTC
Tobais: makes sense, filing new bug.
Comment 5 Martin Flöser 2010-06-12 12:39:22 UTC
*** Bug 199430 has been marked as a duplicate of this bug. ***
Comment 6 Martin Flöser 2010-06-12 12:40:00 UTC
*** Bug 213847 has been marked as a duplicate of this bug. ***
Comment 7 Diggory Hardy 2010-06-21 12:12:51 UTC
Tobias, is there an option to disable the "torus desktop switching"? No bugs for me; it just makes me feel queasy. Though according to 199430 it is a bug...
Comment 8 Michael Leupold 2010-10-10 18:31:51 UTC
I can't reproduce this bug using trunk r1184315. Windows slide as expected when moving across virtual desktops:
- dragging a window to the desktop below makes the current desktop's windows slide out to the top.
- dragging a window to the desktop above makes the current desktop's windows slide out to the bottom.
Comment 9 Tobias 2010-10-10 22:51:02 UTC
Hi, I haven't used KDE in a while since I own a Mac now. It only occurred when you e.g. moved out of desktop 1 to the left to desktop 2, not when going from 2 to 1. See Comment #3 above for a detailed description. 

If it doesn't occur anymore or if nobody else cares, you are free to close this bug.
Comment 10 Hans Chen 2011-09-28 19:54:30 UTC
This seems to work as expected for me on 4.7.1. However, I can still reproduce Bug 213847, which was marked as a duplicate of this bug.
Comment 11 Martin Flöser 2012-04-09 08:10:18 UTC
is this still an issue in a more recent version?
Comment 12 Roey Katz 2012-12-12 03:05:58 UTC
I still get this exact behavior and I am using KDE 4.9.2.
Comment 13 Martin Flöser 2013-01-15 06:19:37 UTC
*** Bug 313255 has been marked as a duplicate of this bug. ***
Comment 14 Thomas Lübking 2013-01-31 12:41:32 UTC
Can please someone encoutering this set the animation speed to slow and make a video?

The effect *looks* weird (because the moved window moves to the bottom as well) but seems technically correct (other windows move downwards)
Tested on git master, but the only change since Sep 22 2011 is

-            data.xTranslate += slide_painting_diff.x();
-            data.yTranslate += slide_painting_diff.y();
+            data += slide_painting_diff;

(API modification)
Comment 15 Aaron Wolf 2013-02-16 22:19:35 UTC
I have been hoping to get time to make a video, may still, but it looks like this whole issue is NOT exactly a duplicate of the bug I separately posted. Here's an easier way to understand one of the problems:

1. Simply have two desktops
2. Turn on wrap-around
3. turn on cursor switching desktops at screen edge
4. move cursor to the right over and over again

Notice that while the wrap-around should always be the same direction if you are always moving to the right, the window sliding switches direction back-and-forth, in other words, it ignores the wrap around and treats moving from desktop two to desktop one as the reverse direction.
Comment 16 Thomas Lübking 2013-02-17 10:15:53 UTC
Ok, i can reproduce it (in pretty much every direction) for the TWO VIRTUAL DESKTOPS case ONLY.

Can you confirm that with more desktops ("in a row") it does not happen for you?
Comment 17 Aaron Wolf 2013-02-17 19:23:23 UTC
Confirmed! With three in a row, everything consistently goes in the expected direction!
Comment 18 vpiotr 2013-08-16 11:21:39 UTC
After upgrading to KDE 4.11 I've noticed something similar to what this bug describes:

I have my desktops organized in two rows, with "desktop navigation wraps around" enabled. Desktop switching effect is set to "slide". When I'm on a desktop in the top row and move mouse cursor to the top edge, desktop is switched correctly, but it slides up, while it should slide down (viewport is moved up, contents should slide down). Behavior is the same for "desktop cube animation". This is visually confusing.

And this is how it looks like: http://spin.ict.pwr.wroc.pl/amo/out.ogv

Also, something weird happenes, when I move a window across desktops. Can't really describe it, so here is another video: http://spin.ict.pwr.wroc.pl/amo/out-1.ogv

Switching left/right with four desktops in a row works fine for me, for all transitions.
Comment 19 Martin Flöser 2014-08-13 06:11:17 UTC
*** Bug 338227 has been marked as a duplicate of this bug. ***
Comment 20 Shi Sherebrin 2016-08-11 10:40:23 UTC
> plasma-desktop -v
Qt: 4.8.6
KDE Development Platform: 4.14.2
Plasma Desktop Shell: 4.11.13

I can reproduce this problem in both directions, when the desktop switching animation is set to either "Slide" or "Desktop Cube Animation", and "Desktop navigation wraps around" is selected.

As long as the number of rows or columns is 3 or greater, switching desktops in any direction, repeated any number of times, produces the expected continuous motion/rotation in the same direction.  If the number of rows is 1 (with 3 or more desktops/columns), switching desktops up or down does nothing and going left/right behaves as above (both as expected).  Same for 1 column and 3 or more desktops/rows.

However, for 2 columns, when I get to the right-most desktop and expect to be able to continue "rightwards" to reach Desktop 1, the desktop slides instead "leftwards" to Desktop 1.  Same problem when sitting on Desktop 1 and trying to go "leftwards" to Desktop 2.  Same issue for 2 rows in the up/down direction.
Comment 21 Vlad Zahorodnii 2018-06-01 06:43:13 UTC
For technical reasons, that's a little bit challenging for effects like Slide or Desktop Cube Animation
to figure out whether they should "roll desktops" when the number of rows or columns in the virtual
desktop grid is equal to 2.

Why is it challenging? Let's imagine a setup with 2 virtual desktops. Now, let's consider two cases:

(a) Current virtual desktop is "Desktop 1" and user switches one desktop to right(i.e. to "Desktop 2").
    In this case, desktopChanged(int old, int current) signal will be emitted, where old=1, and current=2.

(b) Current virtual desktop is "Desktop 1" and user switches one desktop to left(i.e. to "Desktop 2").
    In this case, desktopChanged(int old, int current) signal will be emitted, where old=1, and current=2.

As you see, in both cases, old=1, and current=2. That's too ambiguous.
Comment 22 Martin Flöser 2018-06-01 15:21:37 UTC
KWin core (VirtualDesktopManager) has the information. Maybe we need to add signals like desktopAboutToSwitchToLeft.
Comment 23 Vlad Zahorodnii 2018-06-17 10:38:15 UTC
(In reply to Martin Flöser from comment #22)
> KWin core (VirtualDesktopManager) has the information. Maybe we need to add
> signals like desktopAboutToSwitchToLeft.

I've been thinking about something similar:

Emit currentDesktopAboutToBeChanged(const DesktopChangedData &data),
struct DesktopChangedData {
    uint old;
    uint new;
    bool wrapped;
    EffectWindow *movingWindow;

or just emit desktopChanged(const DesktopChangedData &data), so
Slide effect would use a different wrap function, which is more
"aggressive" with respect to wrapping, if data.wrapped is true.
Same with cube slide effect.

Yet, I'm not sure if it's possible to implement such "behavior".
Comment 24 Roey Katz 2022-03-16 21:34:58 UTC
Created attachment 147534 [details]

Wonderful!! Big pet peeve of mine now for many years, this bug!

On Wed, Mar 16, 2022 at 5:14 PM Nate Graham <bugzilla_noreply@kde.org>

> https://bugs.kde.org/show_bug.cgi?id=185710
> Nate Graham <nate@kde.org> changed:
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |nate@kde.org
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 25 Eric Edlund 2022-03-19 13:35:02 UTC
Git commit 5d9e0be9593f42e58c13ed436ca4f9867aa49148 by Eric Edlund.
Committed on 19/03/2022 at 13:19.
Pushed by ericedlund into branch 'master'.

make gestured desktop switching use natural directions

M  +6    -6    src/virtualdesktops.cpp

Comment 26 Nate Graham 2022-04-15 00:24:44 UTC
Git commit 26a4f75944232166a1de7c977549d52a403fb885 by Nate Graham, on behalf of Eric Edlund.
Committed on 15/04/2022 at 00:09.
Pushed by ngraham into branch 'master'.

Implement desktopSwitching() interface for realtime animations

Added this interface to the VirtualDesktopManager. Realtime touchpad gestures update the interface to allow for mac os style desktop switching.
Also makes gestured switching use natural direction.

M  +7    -0    autotests/test_virtual_desktops.cpp
M  +15   -6    src/effects.cpp
M  +11   -0    src/libkwineffects/kwineffects.h
M  +79   -8    src/virtualdesktops.cpp
M  +23   -0    src/virtualdesktops.h
M  +13   -0    src/workspace.cpp
M  +4    -0    src/workspace.h

Comment 27 Roey Katz 2023-03-02 23:48:28 UTC
I'm on Plasma 5.27.  This bug is still there.  I thought this has gotten resolved?  I've never seen it working correctly, for what it's worth; the slide direction is the opposite of what is expected, when transitioning between one side to the other of a virtual desktop matrix of 2 rows of 3 columns.