(Kinda) supersedes #44
Right now, the layout system in the compositor is extremely rigid and is pretty hostile to work on. If you want to introduce a new layout, you would have to write a lot of logic that's deeply intertwined with the Workspace type.
Moreover, some layouts (such as the #77) might need to store some sort of data (for BSP it would be a cache of a computed window tree). Right now the only solution is to recompute all the data whenever layout data is requested.
The proposed solution would be to separate layout into a Layout trait. This trait would implement common functions like
- Associating each window with a position and size
- Pre-computing the size of a window if inserted at position
i
- Access to state of the layout that needs to be stored.
- ... and more
Another thought that crossed my mind is to not rely on math hand-written by me (or layout authors) but instead delegate that to some existing layouting library like Taffy. We would create some custom nodes to pass into the layout engine, and fully isolate the concerns of the managing windows to it.
(Kinda) supersedes #44
Right now, the layout system in the compositor is extremely rigid and is pretty hostile to work on. If you want to introduce a new layout, you would have to write a lot of logic that's deeply intertwined with the
Workspacetype.Moreover, some layouts (such as the #77) might need to store some sort of data (for BSP it would be a cache of a computed window tree). Right now the only solution is to recompute all the data whenever layout data is requested.
The proposed solution would be to separate layout into a
Layouttrait. This trait would implement common functions likeiAnother thought that crossed my mind is to not rely on math hand-written by me (or layout authors) but instead delegate that to some existing layouting library like Taffy. We would create some custom nodes to pass into the layout engine, and fully isolate the concerns of the managing windows to it.