WIP: Added wlr-workspace-unstable-v1.xml

This is a draft for addressing issue #10.

I likely don't have the C chops to contribute much to wlroots' code (though I might try), but maybe I can talk about protocols.

To accommodate both compositors that have workspaces spanning all outputs, as well as those that have each output with its own independent set of workspaces, this protocol has the concept of 'workspace groups'. A workspace group is a set of outputs that share workspaces. Each output may belong to at most one group. Each workspace group has one active workspace at any one time. This allows arbitrary grouping of outputs, including the two common cases of all outputs sharing a group and of each output being its own group.

There is more to think about here.

Is the protocol sufficient for required atomicity? If an output moves to a different workspace group, then the 'each output may belong to at most one group' requirement will be violated from the perspective of the client until both an output and an output_remove event are processed on the two zwlr_workspace_group_handle_v1 objects. But the compositor can refrain from sending done events until both of these events are sent, so we could say that if the client gets an output or output_remove event, it must wait for the done event before it has a consistent state for what groups all the outputs belong to.

Similarly with zwlr_workspace_handle_v1, if a workspace changes what its number is, the client must wait for the done event in order to see that the 'workspaces are sequentially numbered from zero' requirement is satisfied.

I am also a bit confused about destroy events and requests. If you request to destroy an object, you're just asking to clean up resources - you're not asking the compositor to remove a workspace or whatnot. However, if the compositor does remove a workspace (not just move it to a different workspace group), does it send a destroyed event?

I suspect the general ideas in this protocol are pretty unobjectionable, but potentially more contentious things that I haven't included are:

Workspaces are simply numbered here. Should it be left that way, or should they be defined on a 2D grid? If we do not allow for information about a 2D grid, then if the compositor is laying out the workspaces this way, panels will not be able to reflect that in how they display workspaces, and they will not be able to implement 'move to workspace left' and 'move to workspace up' functionality, etc.

Should workspaces and/or workspace groups have names?

Here are some events/requests I have not included

zwlr_workspace_manager_v1:

• request: create workspace group

zwlr_workspace_group_v1:

• request: add an output to the group
• request: remove an output from the group
• request: add a workspace to the group
• request: remove a workspace from the group
• request: set a name as a string
• event: name as a string

zwl_workspace_v1:

• event: name as a string
• request: move (change the number of the workspace - processed as an insert to keep numbers sequential)
• request: set name as a string

There is also some question of whether only one workspace can be active at a time. In compositor workspace overview interfaces, you can often see multiple workspaces. However, that's not inconsistent with only one of them being 'active', active doesn't have to mean visible, so I'm not sure if that's a problem.