Why not just provide width% and height% instead of specifying layoutdata

VishwasGagrani

Feathers UI can make things easier by allowing a component's layoutData property to only accept width and height in %. Without needing to specify which type of layoutdata class (HorizontalLayoutData or VerticalLayoutData etc) needs to be instantiated. This is because the type of layout can be assigned by the layoutgroup by looping through it's children components. ( As Layoutgroup has both information about it's own layout and the component inside it )
Eg. This

var lg:LayoutGroup = new LayoutGroup( ) ;
lg.layout = new HorizontalLayout()
var button:Button = new Button();
button.layoutData = new HorizontalLayoutData( 50,50) <<<<
lg.addChild(button);

can be simply

var lg:LayoutGroup = new LayoutGroup( ) ;
lg.layout = new HorizontalLayout()
var button:Button = new Button();
button.layoutData = new LayoutData( 50,50) <<<<
lg.addChild(button)

joshtynjala

Not all layouts necessarily support width and height values as percent. Some layouts have other layout data properties that aren't supported by other layouts.

For instance, AnchorLayout doesn't support percentWidth and percentHeight.AnchorLayoutsupportstop,right,bottom, andleft`, but other layouts do not.

That's why each layout has its own layout data class.

VishwasGagrani

joshtynjala
But why not the Layoutgroup can take care of what class of layout need to be applied?
I am saying because in a highly nested layout mistakes like applying a wrong class of layoutdata (eg. HorizontalLayoutData instead of VerticalLayoutData ) makes it very difficult to find the issue.
Layoutgroup knows the layout it has. Layoutgroup has got the children components. And whatever data it needs % , or anchor data etc . It can take the responsibility of looping through the children and assigning the values. Thus automating this part.

joshtynjala

VishwasGagrani Layoutgroup knows the layout it has
It can take the responsibility of looping through the children and assigning the values.

While this might be technically possible for the layouts that are included with Feathers UI, I designed the framework to allow people to create completely custom layouts too, and those custom layouts should support their own layout data classes that can have properties that may not be supported by other layouts. I would prefer if custom layouts and built-in layouts are treated equally, so built-in layouts should not get special treatment.

Don't get me wrong. I see the value of your suggestion. Over the years, I have had to help a few people who had accidentally used the wrong layout data class. There's no error or warning when you choose incorrectly, which I admit isn't ideal. I'll think about it some more. Perhaps I could consider adding a define where you can enable a stricter mode that immediately throws an error when an incompatible layout data is used.

On the other hand, I mentioned custom layouts above. You could get exactly what you want by creating your own custom layout classes where you copy the code from HorizontalLayout and VerticalLayout, and them modify them to use a different, shared ILayoutData implementation that you create.