workspace-management: Implement move_to_workspace requested

[ids1024]

Needed for cosmic-workspaces.

Requires pop-os/cosmic-protocols#21. This dependency will need to be updated here when that is merged.

[ids1024]

Updated. I had to make the seat optional Shell::move_window, like my earlier version, since there's no seat associated with the operation here. Which should be fine.

The output argument to the protocol is ignored, since there is only one output per workspace, even with workspace_mode:global. The argument still makes sense to have in the protocol since cosmic-workspace-unstable-v1 allows multiple outputs per workspace, even if the cosmic-comp implementation doesn't currently do that.

Seems to be working fine, with workspace_mode set to global or output bound.

[Drakulix]

Updated. I had to make the seat optional Shell::move_window, like my earlier version, since there's no seat associated with the operation here. Which should be fine.

This will obviously cause the pointer/focus to not swap over to the new output/newly mapped window. Given we only really support one seat and the last active one probably is the one that initiated this action to be send by our toplevel-management client, we could also use state.common.last_active_seat. Or is switching the focus away from cosmic-workspaces in this case actually not desirable?

Maybe we should extend the toplevel-management request to take a nullable seat?
Or better add an explicit request to focus a given toplevel on a given seat later?

The output argument to the protocol is ignored, since there is only one output per workspace, even with workspace_mode:global. The argument still makes sense to have in the protocol since cosmic-workspace-unstable-v1 allows multiple outputs per workspace, even if the cosmic-comp implementation doesn't currently do that.

Sounds reasonable. 👍

[ids1024]

Or is switching the focus away from cosmic-workspaces in this case actually not desirable?

I'm using this for drag-and-drop of a window to a workspace in cosmic-workspaces. As currently implemented it makes sense not for this to focus the surface.

Having the option to focus the surface is useful, but using another request for that is reasonable enough.

[Drakulix]

I'm using this for drag-and-drop of a window to a workspace in cosmic-workspaces. As currently implemented it makes sense not for this to focus the surface.

Right, then there is a reason to take an Option here, agreed.

Having the option to focus the surface is useful, but using another request for that is reasonable enough.

Good. Then we can do this later and that doesn't have to concern this PR.