Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#6925 closed bug (fixed)

Switching workspaces via shortcut kidnaps window

Reported by: humdinger Owned by: czeidler
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Change History (7)

comment:1 in reply to:  description Changed 9 years ago by bonefish

Status: newin-progress

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.

comment:2 Changed 9 years ago by humdinger

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

comment:3 Changed 9 years ago by bonefish

Owner: changed from bonefish to axeld
Status: in-progressassigned

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.

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by czeidler

Owner: changed from axeld to czeidler

comment:6 Changed 9 years ago by czeidler

Resolution: fixed
Status: assignedclosed

Hopefully fixed without further regressions in hrev39707.

comment:7 Changed 9 years ago by humdinger

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

Note: See TracTickets for help on using tickets.