Manual tiling is secondary to auto tiling (to me), but it's still a useful mode to have. I've factored it into my design for layouts and workspaces, but have not included any implementation of a manual layout.
The biggest difference between a manual layout and some other layout is that a manual layout separates the notion of "space on the screen" and "space used by a client." Namely, a manual layout is divided up into containers, and each container may contain zero or more clients.
Containers with clients are easy—we just show the client on top of the stack of that container. But containers without clients are hard if we want to have some visual representation of that container (i.e., a border). They are hard because workspaces and layouts assume a model of a "Client" as the unit of things to place, display or hide. A border around an empty container doesn't really fit the model of a client, but it may have to unless we want to build some notion of artifacts into the workspace/layout models.
The aforementioned describes the design issues with a manual layout. The actual implementation of a manual layout should be pretty straight-forward. It's a tree where all leaves are containers and all non-leaves represents splits (which can be horizontal or vertical).
The width and height of each container is defined as a ratio, where the width and height ratio of the root node is always 1.0 and 1.0, respectively. The height ratio of a horizontal split is equivalent to the height ratio of its parent. Similarly, the width ratio of a vertical split is equivalent to the width ratio of its parent. The height ratio of a vertical split is equivalent to the sum of the height ratios of its children, and the width ratio of a horizontal split is equivalent to the sum of the width ratios of its children.
There are a couple invariants for this tree:
Other than the tree consisting of a single container, no container may exist without any siblings. That is, every split corresponds directly to at least two containers.
Summing the height and width ratios of all splits should equal 1.0 and 1.0, respectively.
(N.B. I implemented something like this in pytyle2.)
A similar data structure for automatic tiling can be found in layout/tree.go. It remains to be seen whether it will be usable for manual layouts, but I suspect so.
Manual tiling is secondary to auto tiling (to me), but it's still a useful mode to have. I've factored it into my design for layouts and workspaces, but have not included any implementation of a manual layout.
The biggest difference between a manual layout and some other layout is that a manual layout separates the notion of "space on the screen" and "space used by a client." Namely, a manual layout is divided up into containers, and each container may contain zero or more clients.
Containers with clients are easy—we just show the client on top of the stack of that container. But containers without clients are hard if we want to have some visual representation of that container (i.e., a border). They are hard because workspaces and layouts assume a model of a "Client" as the unit of things to place, display or hide. A border around an empty container doesn't really fit the model of a client, but it may have to unless we want to build some notion of artifacts into the workspace/layout models.
The aforementioned describes the design issues with a manual layout. The actual implementation of a manual layout should be pretty straight-forward. It's a tree where all leaves are containers and all non-leaves represents splits (which can be horizontal or vertical).
The width and height of each container is defined as a ratio, where the width and height ratio of the root node is always 1.0 and 1.0, respectively. The height ratio of a horizontal split is equivalent to the height ratio of its parent. Similarly, the width ratio of a vertical split is equivalent to the width ratio of its parent. The height ratio of a vertical split is equivalent to the sum of the height ratios of its children, and the width ratio of a horizontal split is equivalent to the sum of the width ratios of its children.
There are a couple invariants for this tree:
(N.B. I implemented something like this in
pytyle2
.)