Allow constructor-based UI definitions

[corliss]

From XAML and Linq to Xml, the preferred style of creating object trees is the nested construct. This also works very well with Intellisense.

Unfortunately Eto still requires constructing objects and layouts and then wiring them together.

Goal: make it easy for entire forms to be defined in a nested constructor flow without the use of extra variable definitions.

This feature is much simpler to implement now that Layouts are containers.

[cwensley]

I prefer the use of object initializers, which is not far off from specifying parameter names of a constructor directly:

new Panel { Content = new Scrollable { Content = new Drawable { Size = new Size(100, 100) } } }

As for table/pixel/dynamic layouts, how would you fashion a constructor that specifies the location of the child controls?

I'd hate to see an entire form defined entirely with one really long line of code.. (;

[corliss]

Why would one use an initializer to construct a table? Surely that's what a constructor is for.

Something like this:

myTable = new Table(
       new Row(new Label(), new TextBox().WithScaledWidth()),
       new Row(new Label(), new TextBox()));

As an aside, the terms xscale and yscale are misnomers since they relate to lengths, not locations. That's why the example above proposes WithScaledWidth().

Summary: Table's ctor is simple: Table(params Row[] rows) Row's ctor is also simple: Row(params TableItem[] tableItem) A TableItem can be implicitly created from a control: implicit TableItem(Control c); or via the WithScaledWidth() and WithScaledHeight() extension methods on Control.

Note that class TableItem itself can be eliminated if Control supports the scaling properties directly. I don't see any harm in that approach either. The fluent extension methods may help readability in either case.

No magic here. The intermediate objects can also be assigned to variables and used directly.

There's no requirement to have all the objects necessarily be constructed at the same time - so your concern about unduly large lines of code is easily avoided by breaking construction through the use of intermediate variables - if the author sees fit.