On 15/07/2026 19:32, Andy Goryachev wrote: > > * > Yes, they don't need to be public immediately, although they > definitely can be as they're nothing more than a "copy" of the > layout panes we already have, but packaged without the Node > dependency. We would need pretty quickly the Node implementing > the Layoutable interface (which opens the path for people writing > their own virtual layouts). > > > > One thing I wanted to mention is that these layout classes can > probably be static (unless they need to keep some internal state like > HBox.tempArray). If I understand the logic, there is no need for the > Layoutable interface either, the owner Node is merely delegates > layoutChildren() to the corresponding layout class, passing all the > necessary information (scale, snap, etc.)
If you want virtual layouts to compose, you need to be able to point at something. Let's say you have a simple layout: HorizontalLayout[ Graphic + Text ] This can be relatively static, agreed. However, if you want something more complicated: HorizontalLayout[ Graphic + VerticalLayout[Title + Subtitle] ] ...then how would the static call look like to HorizontalLayout? Furthermore, HorizontalLayout would need to accept both Node and Layout somehow if they don't implement a common interface (so Object[] ?) Also, layouts often have a ton of parameters to tweak: padding, alignment, spacing, margins, snapToPixel, etc... that's a lot of things to pass in to a static layout. This quickly invites a "parameter" object, at which point you can just make the Layout an instance (which gives more flexibility for also caching things and other interal bookkeeping). The best you can do as a "static" solution is to have some helpers, like the SpaceDistributor class I once created, but the actual layouts are *far* more complicated, and I don't think you can easily get away with having them just be a static method call. > > In other words, it might be possible to achieve the main goal of code > reuse without any changes to the public APIs. The layout classes can > be made public later, once matured. Only if you accept the layouts would be extremely limited (no mixing of Layouts and Nodes). Regardless, there wouldn't be any changes to existing public API's by having Node implement Layoutable. At most, there would be one or two methods to offer a better abstraction for just plainly exposing "getProperties()" on Layoutable. Implementing an interface that exposes methods that Node already has is a source and binary compatible change. --John > > What do you think? > > -andy
