Creating controls is unsound

[NoraCodes]

Creating controls is unsound at the moment. libui enforces a tree structure. We should enforce it in the API.

I would like to do this by creating a trait which permits adding a control, and implementing it on all containers (like windows and grids and boxes).

The question is, should we have individual methods for each control:

let btn: &mut Button = window.add_button("Button text!");

or should we have an enum with all the controls?

let btn: &mut Button = window.add(Controls::Button("Button text!"));

[NoraCodes]

It would perhaps be useful to maintain a hashmap within each of these container controls with each component, which the user could name.

This is kind of problematic because we have to decide:

1. Does the user have to name every control?
2. What happens when the user gives two controls the same name?

[barzamin]

by "creating controls is unsound", what exactly do you mean? can you give an example?

[NoraCodes]

When you make a control, if you don't add as a node in a tree whose root is ultimately a Window or other appropriate control prior to UI handle deinit, the process will abort without unwinding, which is (afaik) not sound.

[barzamin]

Oh, you mean, if you ::new() a control and don't add it to something else, everything freaks out and crashes? how long does it take to do that? does it happen on the next repaint or something like that?

…

On Sat, Dec 22, 2018 at 10:34 PM Leo Tindall ***@***.***> wrote: When you make a control, if you don't add as a node in a tree whose root is ultimately a Window or other appropriate control, the process will abort without unwinding, which is (afaik) not sound. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/LeoTindall/libui-rs/issues/54#issuecomment-449613791>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATM34XnmbuNA9SMb11o_Kns2xKDSy5yIks5u7wfTgaJpZM4ZXouk> .

[jonas-schievink]

Aborting in itself is safe and sound if done deliberately (eg. by a failed assertion) but not if it happens as a result of undefined behaviour (on the Rust or C side). Of course aborting is still suboptimal in general and is better avoided.

[NoraCodes]

I think the solution is to implement a trait for containers (HorizontalBox, VerticalBox, Window, Grid, etc) which provides functions to create new controls as children, thus never allowing controls to exist outside of the tree.

This seems like a nicer API anyway, to me.

[academician]

Alternatively, controls could be created "lazily", such that they are not actually created until attached to a node.

[NoraCodes]

If we do make an API whereby each container has methods to create its children, whether we do so lazily or eagerly, we could also place a &'ctx UI within each control, which would obviate the need for constantly passing around &'ctx UI. It would only be needed on associated functions without a receiver.

[NoraCodes]

This discussion is potentially relevant to #92