Bug 185710

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

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.

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).

Tobais: makes sense, filing new bug.

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

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

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...

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.

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.

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.

is this still an issue in a more recent version?

I still get this exact behavior and I am using KDE 4.9.2.

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

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)

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.

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?

Confirmed! With three in a row, everything consistently goes in the expected direction!

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.

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

> 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.

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.

KWin core (VirtualDesktopManager) has the information. Maybe we need to add signals like desktopAboutToSwitchToLeft.

(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".

Created attachment 147534 [details]
attachment-32744-0.html

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>
wrote:

> 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.

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

https://invent.kde.org/plasma/kwin/commit/5d9e0be9593f42e58c13ed436ca4f9867aa49148

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

https://invent.kde.org/plasma/kwin/commit/26a4f75944232166a1de7c977549d52a403fb885

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.