This feature would be very nice to have. The initial idea is to implement it as a Layout instance. However, as it is now, that's impractical (since Layouts don't carry mutable state).
Thus, the following changes would have to be made:
[x] Each OrderEntry is a tree of windows and splits, as i3 handles all of it's windows
[ ] verify that no illegal structure of the tree is possible.
[ ] A Layout is a strategy allowing to do multiple things, namely:
[ ] Restructure an arbitrary tree into a layout-specific, canonical shape.
[ ] Handle inserting and deleting windows.
[ ] A "manual" layout would emulate i3's behaviour by inserting windows at the cursor.
[ ] The tree converions mentioned above should follow a convention (ie. the master is always the left-most leaf in the tree, that is, top left).
[ ] So, superficially, everything remains roughly the same if you use the simple layouts already present (like the various *Stack).
[ ] More complicated layouts, like Grid and Monocle would need some additional thought, but a simple convention (or two), combined with the idea that layouts still build the geometries associated with a tree of clients, should make them entirely possible.
Based on the points above, some other aspects of the already existing infrastructure will see some change: Depending on whether the tree holds information on the splits (and I guess it should), focus and window swap can be moved out of layouts, as well as the ugly hack with new_client_as_master (maybe). Client set updates should also happen as soon as possible, to avoid complication.
This feature would be very nice to have. The initial idea is to implement it as a
Layoutinstance. However, as it is now, that's impractical (sinceLayouts don't carry mutable state). Thus, the following changes would have to be made:OrderEntryis a tree of windows and splits, as i3 handles all of it's windowsLayoutis a strategy allowing to do multiple things, namely:*Stack).GridandMonoclewould need some additional thought, but a simple convention (or two), combined with the idea that layouts still build the geometries associated with a tree of clients, should make them entirely possible.Based on the points above, some other aspects of the already existing infrastructure will see some change: Depending on whether the tree holds information on the splits (and I guess it should), focus and window swap can be moved out of layouts, as well as the ugly hack with
new_client_as_master(maybe). Client set updates should also happen as soon as possible, to avoid complication.