Currently under discussion in sway is the addition of some layouts that automatically arrange windows, inspired by the behavior of some Awesome/Xmonad features. Bringing it up for discussion here.
Details here: SirCmpwn/sway#1024
How would this interact with, for example, layout restoring? Adding such a feature would mean a complete shift of paradigm.
It should fit into the current layout save/restore mechanism, no?
If I specify a specific layout for a workspace but then load a layout file, what wins? The layout file or the predefined layout?
Isn't that already an issue?
We don't have predefined layouts, so why would it be?
The layout file would of course show that the layout for that workspace is an auto layout, and arrange it appropriately. I'm looking at the layout JSON now and not seeing any reason why these layouts couldn't be represented in it.
Layout files don't necessarily represent entire workspaces. You can insert layouts into arbitrary positions in the tree (below workspaces). So the layout file might be in violation with the predefined layout of the workspace.
You can insert auto layouts anywhere in the tree in the sway patches I linked to, and insert not-auto layouts anywhere in an auto tree. It behaves just like any other kind of layout.
OK, I misunderstood the feature then. I'd be open to implementing such new layouts. I'd like to avoid extending workspace_layout because this is already causing headache.
You mean that you'd like to add new layouts without supporting them in workspace_layout? That sounds like a bad idea imo. To answer your question directly, the layout file wins.
No, the opposite. I don't want to touch anything related to the workspace_layout feature. Extending the usual container layouts (splitv, splith, tabbed, stacked) with new modes sounds like a neat idea to me.
My feeling is that implementing this is quite tough, but that's something we can only judge when we have a PR for it.