Create layout managers

[LazyOxen]

This would allow a developer to quickly put together an application without having to calculate positioning and could offload some of the resizing logic.

A widget could default to absolute positioning of child widgets if no layout is specified.

[LazyOxen]

Some thoughts about implementation from some discussion with @stratact

• Should a layout be a widget? or should a widget have an optional layout.
  • if a widget is a layout, then you would still need to specify position and sizing information
  • if a widget has a layout, the layout would essentially "inherit" the size information of the owning widget, and use that to delegate space to subwidgets
• In the case of a window, should it have multiple widgets? or a layout (widget), that contains subwidgets?

[AyeTbk]

TLDR: I think container widgets being layouts would be better.

@LazyOxen by widget having a layout, do you mean the container widget has a layout, like java's Swing, or the contained widgets have layout information and the container has no layout information, like Python's Tkinter?

I hope the former, because tkinter's way is error prone (how do you handle a container with widgets asking for 2 different layouts? tkinter throws an exception).

So, we either have:

• (A) a bunch of different container widgets, each being a layout, placing and sizing their children as they see fit

or

• (B) a simple Container in which:
  • widgets could be placed and sized manually by default
  • could be given a Layout object to compute position and size of the children

I prefer (A).

Different layout might need different layout information for their children. For exemple, say we have a PackLayout (stacks its children one after the other) and a GridLayout (places its children in the cells of a grid). PackLayout might not need any such information but GridLayout would require a X and Y index to specify a cell (plus optionnal cellspanX and cellspanY for exemple, to tell that a certain cell should stretch across many columns or rows).

If going with option (B), you would have to add a child to the container and then also set the layout information on the Layout object for that same child. What if a layout (like GridLayout) absolutely needs that information? In the (B) case, you are not forced to give the information to the Layout object (you could forget to do it). The Layout object could also be given information for a widget that isn't even in the container. Also, what happens if, for a given container, its Layout object is changed? (and if this shouldn't be allowed, then (B) seems pointless and (A) seems like the best choice). I'm not saying it's impossible to get it to work, just that (B) is not the most elegant of the two.

Going with (A), we can require the layout information when adding a child, and know for sure, at compile time, that no child widget is without it's required layout information. The downside of (A) seems that it would be less flexible than (B), but what else than a plain Container would need a Layout object anyway? and is there any value to being able to change the Layout object at runtime without changing the Container itself? No and no, at least from my point of view.

Also, if it's relevant to know:

• JavaFX uses (A)
• WinForm and WPF use pretty much (A), but encourage to use only the default layout, which uses grouping, docking and anchoring of the children to achieve all sorts of layouts (and it works great with the Visual Studio GUI designer)

As for the case of a Window, it think it should have just one widget, which gets stretched to fill the entirety of the window: if more than one widget is needed, then the window should be given a Container as its sole widget (by the user of OrbTK).

[jackpot51]

@simondesloges Thanks for the input! I am working on something like what you have suggested