You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like what we really want is a language for describing the a dynamic flexible layout of the entire simulation. This seems a daunting task! I haven't really been satisfied with the Java layout containers. Maybe a simple rule that still gives us complete flexibility is to treat every layout-able object as having a Property, then writing rules for aligning objects relative to other Property. Then if we want a button to align to the top right corner of the visible stage bounds (with some padding), it would have a rule that does so. Then if we want a control panel below that button, it would have a separate rule. Then when the top-level layout changes, the Property notifications cascade and everything relays itself out properly.
And we don't even need to give names for the relative layout strategies such as "within parent bounds in the top right with paddingx and paddingy) (there would be many of them (!) ), we can just use a function in each case and use vanilla scenery code.
// This is a fictional case where there is a button in the top right of the screen, and a control panel below it.visibleScreenBoundsProperty.link(function(visibleScreenBounds){button.right=visibleScreenBounds.right-insetX;button.top=visibleScreenBounds.top+insetY;});buttonBoundsProperty.link(function(buttonBounds){controlPanel.right=buttonBounds.right;controlPanel.top=buttonBounds.bottom+insetY;});
Activity
samreid commentedon Oct 23, 2015
It seems like what we really want is a language for describing the a dynamic flexible layout of the entire simulation. This seems a daunting task! I haven't really been satisfied with the Java layout containers. Maybe a simple rule that still gives us complete flexibility is to treat every layout-able object as having a Property, then writing rules for aligning objects relative to other Property. Then if we want a button to align to the top right corner of the visible stage bounds (with some padding), it would have a rule that does so. Then if we want a control panel below that button, it would have a separate rule. Then when the top-level layout changes, the Property notifications cascade and everything relays itself out properly.
And we don't even need to give names for the relative layout strategies such as "within parent bounds in the top right with paddingx and paddingy) (there would be many of them (!) ), we can just use a function in each case and use vanilla scenery code.
@jonathanolson what do you think of that plan?