Switching workspaces via shortcut kidnaps window

[humdinger]

This is hrev39660.

Since the recent window resizing changes, when you switch workspaces via CTRL+ALT+Cursor you'll take the active window with you, as if you'd have SHIFT pressed as well.

[bonefish]

Replying to humdinger:

Since the recent window resizing changes, when you switch workspaces via CTRL+ALT+Cursor you'll take the active window with you, as if you'd have SHIFT pressed as well.

Oh, my... I don't even know where that is implemented and I certainly haven't touched it. I'll see what atrocities it is committing that my changes could affect it.

[humdinger]

Maybe this can help. Apparently Axel had a similar issue.

[bonefish]

Assigning to the one who might actually know what Desktop::_SetWorkspace() is supposed to do. For some reason it is always moving fMouseEventWindow to the target workspace (if there is one). At least the calls from the AS_ACTIVATE_WORKSPACE message handlers expect the moveFocusWindow parameter to indicate that, if false, no window is moved, and otherwise (supposedly) the keyboard focus window.

That aside, the protocol for the AS_ACTIVATE_WORKSPACE message is insufficient anyway, since by the time the message is handled in the app server it is no longer clear which window was requesting the operation -- using the focus window is working only in most cases.

[Disreali]

Tested on hrev39652 and it only occurs if the mouse pointer is on or near a window boarder. I would guess that the recent work on ticket:4493 is involved.

[czeidler]

Hopefully fixed without further regressions in hrev39707.

[humdinger]

Seems to work flawlessly. Same for #6935. Thanks for saving this cool feature from revertion. :)