I've made a Gist with the images: https://gist.github.com/hjohn/d2c5a3d15005524ee4e8a7c66cd9e4b1
On 14/07/2026 00:22, Michael Strauß wrote: > Interesting, this is quite similar to an experiment of mine for a new > type of skin that would allow developers to > change/extend/reuse/recombine existing skins (I'm calling that > composable skins). That also sounds interesting; Skins are a very messy area still, and although user exposed, are barely workable especially since half of the logic you'd need to make a good skin is still locked behind internal API's. > Like you, I wanted to untangle layout algorithms from layout > containers and control skins, and give them an actual API. In my > experiment, I've moved the layout code of HBox to HLayout (an > implementation of an interface essentially identical to Layoutable in > your proposal), and HBox just delegates its methods to this layout > algorithm. Yes, that's exactly how it could work. Once an HBoxLayout or HLayout exists that does what HBox does, HBox can just be a mostly empty shell that has the relevant properties. The layout itself is then reusable. > A new ComposableSkinBase then accepts a layout algorithm, to which all > layout-related methods are delegated (much like with HBox). > > Where your proposal goes beyond my experiment is the ability to have a > tree of layout algorithms, each affecting different nodes. That seems > like a very interesting and powerful idea! Yes, the primary thing to make that work is to have a common API between Node and a Layout, which would be the Layoutable interface. Then a Layout can have a list of Layoutables, and it wouldn't need to care if they're Nodes or other layouts or a mix. --John
