On 13/07/2026 21:00, Andy Goryachev wrote: > I think you are on to something. > > I like the idea of extracting the layout logic into a set of reusable > *Layout classes. Swing has its own Border, Grid, Flow, ... layouts > that can be set on a Panel, but we don't have to do that - a reusable > class would suffice.
Sure, it wouldn't quite work like how Swing does it, but close enough I suppose. > Additionally, it might contain the per-node layout constraints (I > never liked the idea of the "attached" properties like HBox.setHgrow() > stored in properties). I'm not so sure; the main difference between the way it currently works, and how I think you'd like it to work is that when you want to track properties with the container (which would already be possible now), it would require instance methods instead of static methods (note how HBox.setHgrow doesn't actually know for which HBox it is setting the constraint). That would be a significant API break, as the current static API calls couldn't possibly work anymore then. So I'm pretty sure that ship has sailed, and in the end doesn't make the system any easier or more difficult to use for the users of the system. What would make a huge difference is when we make these properties CSS stylable. I've been running such a system for well over two years now, and it is so nice to just be able to set these things in CSS, instead of having to break your styling flow with adding these properties in code. This is IMHO the biggest styling gap we have currently, forcing users to do this in code. However there is a simple path to solve this (PR https://github.com/openjdk/jfx/pull/1714) after which I think it would barely matter to anyone anymore how and where these properties are stored exactly. > These layout classes can start as implementation detail, and once > sufficiently developed, could be exposed as public APIs for use in > skins and custom components. As an implementation detail, it would > not require API changes in the existing controls It can even rely on > the existing attached properties. 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). > > What do you think? > > -andy > > PS. some formatting and possibly images got lost in the mail. Here's a gist with better formatting and graphics: https://gist.github.com/hjohn/d2c5a3d15005524ee4e8a7c66cd9e4b1 I've also updated this proposal slightly. I realized that the LayoutContext interface was mixing two concerns, and it was one of the weakest parts of the argument -- it is now a simpler RenderScaleContext interface. --John
