Core Feature: multi-head output

way-cooler / way-cooler

Wayland compositor for AwesomeWM

http://way-cooler.org

MIT License

2.14k stars 75 forks source link

Core Feature: multi-head output #64

Closed Timidger closed 7 years ago

Timidger commented 8 years ago

This is a very sought after feature, and will need to be broken down into different tasks in order to achieve it.

[x] Change workspace initialization to include initializing all outputs, similar to how i3 places a new workspace on each output, starting at 1, then 2, etc...
[x] Add a new invariant to the tree: Each output needs to have at least one workspace. Add it to validation checks and add tests on all methods that might invalidate this (such as workspace pruning movement/pruning methods).
[ ] ~Rewrite the container movement / focus movement methods to account for moving into another output at the edge of a workspace.~ Since they are individual buffers, we do not know where the output exists at. This feature has been punted. An explicit command to move to a workspace/output is used instead, like in i3
[ ] Ensure we use the correct resolution setting functions from wlc.
[x] Gracefully handle adding and removing outputs to the tree.

SnirkImmington commented 8 years ago

Additional tree commands would include

[x] Move view between workspaces
[x] Move focus between workspaces
[ ] Move workspaces between outputs

Also, OSX is really clever about saving view configurations when monitors are plugged/unplugged. I suggest we look into saving (in memory) some form of the tree when a monitor is unplugged and attempting to restore layouts when it is added back.

Timidger commented 8 years ago

We have the first two already by the way.

I will worry about niceties after this is implemented

Timidger commented 8 years ago

We could always just keep an entire copy of the tree around in memory, and would probably be the best way to go about that, but it would have to be tested especially for e.g long lived disconnects from other outputs. How long should these copies live? How does it handle missing views? What about edge cases like all the children of a container being removed, we need to remove the container now. What if a third, different output is connected before hand? Does it overwrite the last one? What happens if we connect all three together? Disconnect the third one?

This is complicated enough to require its own issue. Feel free to make another issue about it, but it will probably not be done by v0.4.0 unless I can get help.

DorianGray commented 8 years ago

Maybe link it to what layout is assigned to via EDID data and store on disk? When a monitor is plugged, try to move portions of the layout described to the new monitor unless already assigned?

Alternatively, take the awesome approach and don't try to implement this. Rather, expose APIs and allow users to write scripts to provide this functionality. I would prefer this route, personally.

Timidger commented 8 years ago

@DorianGray, yeah perhaps this would be better implemented in some client program. If we expose ways to set the layout of various workspaces, it's possible to setup a daemon or something that can do that heavy-weight approach of keeping a copy of the tree around in case the user wants to restore it. It does seem a little beyond the scope of our wm to handle something this complicated.