Are Layout Managers Necessary?

[bbb651]

Every LayoutManager can be trivially implemented as a LayoutGenerator by delegating the call to the underlying LayoutGenerator instead of returning it, with no worse performance (I think it would even be better because it saves an ipc roundtrip each call).

LayoutGenerators are composable and flexible in a way LayoutManagers aren't, because they allow you to combine LayoutGenerator in other ways than "one is active". Some examples of what this enables:

• Scratchpad layout that wraps a CyclingLayoutGenerator
• Niri-like scrollable layout, can be used inside a master stack layout to make only the stack scrollable, or nested within itself
• Splitting outputs into multiple virtual outputs where different layouts are applied

(You can workaround it by having a LayoutManager that delegates to a single LayoutGenerator, but at this point you're fighting the api and lose bulitin LayoutManagers)

[Ottatop]

Whoops just saw this (my inbox is flooded with CI failed emails)

I came up with the idea of layout managers as a spur-of-the-moment thing without much thought put into it. Now that you've mentioned it, they do seem very redundant. It's essentially proxying for any given layout generator(s) LayoutArgs -> LayoutManager -> LayoutGenerator -> Vec<Geometry> when we could just send the args straight to the generator directly, LayoutArgs -> LayoutGenerator -> Vec<Geometry>. Probably should just cut out the middle man.

I'm interested in the idea of composable layouts. #271 is transitioning to a tree-based layout system, which leans into the idea of composing LayoutNodes from different generators into a single layout. I'll see if I can implement some of the ideas here there.