Bug 308042

why should the "desktop navigation wraps around" control the animation? It's 
only about how the switching of desktops works

to be more precise: "how the 'switch to next/prev desktop' shortcut works"

it does not even hold for the variant that takes a window to the next desktop, nor how scrolling the desktop works (and i'm not sure about the point of that option at all)

Martin: perhaps it should not affect the animation, but currently the effect is inconsistent and unpredictable: It affects one animation (slide) but not the other (cube).

Thomas: Currently the "desktop navigation wraps around" option affects the following forms of navigation:
  -keyboard shortcut
  -window dragging
  -slide animation

But does not affect these:
  -desktop scrolling
  -pager scrolling
  -cube animation

I think it *should* affect these:
  -keyboard shortcut
  -window dragging
  -desktop scrolling
  -pager scrolling

The "slide" and "cube" animation wrapping should instead be controlled by another "animation wraps around" option, if anything.

No?

Resp.:
is the bug that the cube visually starts a rotation despite the window is not gonna be dragged to another desktop because of this setting?

The animation has no word on the actual behavior, the inconsitence is between dragging windows, resp. "next desktop" shortcut (obeys) and the "window to next desktop" shortcut (disobeys) whether by intention or not, i don't know.

Desktop and pagers are external, they'd have to provide such setting or read the kwin one and obey it (due to the protocol, there's no way to control this from the WM) - you'd have to file a bug/wish against plasma (or any 3rd party pager) for this.

I just discovered something new, so let me clearly restate the issue:
Say we have 9 desktops in a row, and wrapping is enabled.

a. switch from desktop 1 to 5
b. switch from desktop 1 to 6

The slide and the cube animations both perform similarly. The animation takes the shortest path to the target:

In (a), the animation takes the path over desktops 2->3->4->5.
In (b), the animation takes the path over desktops 9->8->7->6.

Now disable wrapping, and repeat (a) and (b) for both slide and cube animations:

In (a), the animation takes the path over desktops 2->3->4->5.
In (b), for *slide*, the animation takes the path over desktops 2->3->4->5.
In (b), for *cube*, the animation takes the path over desktops 9->8->7->6. (bad!)

expected result:
In (b), for *cube*, the animation takes the path over desktops 2->3->4->5.

Now it is very clear to me that this is a bug. The slide animation has been specifically programmed to respond to this setting, so for consistency the cube animation should too.

> is the bug that the cube visually starts a rotation despite the window is not
> gonna be dragged to another desktop because of this setting?

You mean "start animation when moving windows towards screen edges" ? No, that is not what I am talking about.

> The animation has no word on the actual behavior, the inconsitence is between 
> dragging windows, resp. "next desktop" shortcut (obeys) and the "window to next
> desktop" shortcut (disobeys) whether by intention or not, i don't know.

I don't know either :-)

The slide and cube animation do not need to be consistent as they are mutual exclusive animations.

The cube effect is intended to break with the real world situation. E.g. the normal cube effect reorders the desktops on an object which does in that way not exist. The same is true for the cube animation: it adds 90 degree animations in a way that is not realistic at all.

The animation is programmed to always take the shortest path. This is a deliberate decision to minimize the animation steps. This will not be changed.

Overall I do not think that the way cube is defined the wrap around setting should be honored. In the cube effects the desktops are wrapping around always. It's not possible to not wrap around.

Given that I'm sorry to say that I don't see a bug at all. If we consider it, it is a feature request. As explained I do not see any reason to implement this feature request as I consider the effect to only work in exactly this way.

To evaluate whether we should consider feature requests they need to be discussed first with the larger userbase on brainstorm.forum.kde.org. Even though I mark this report as wontfix I invite you to discuss on brainstorm whether this is a required functionality.