Convenience methods to add multiple children to layouts, etc

[NoraCodes]

Several controls, especially Group and {Vertical, Horizontal}Box, could be much more ergonomic to use if they provided an interface looking something like the following:

fn add_all(&mut self, ctx: &UI, children: Vec<Control>)

These are of course not precisely the correct types, but the general shape of the interface is correct. Adding many children is a pain, and this would make it easier.

Bonus points if it takes impl Iterator<Item=Control> or similar.

[delbonis]

Is there a reason we have to pass the ctx: &UI everywhere by hand? Is there a way that it could be hidden and inferred when needed?

[NoraCodes]

Yes. The `UI` context reference allows `iui` to ensure, at compile time, that you your code will not call `libui` functions prior to initialization, which would be unsound.

…

On Thu, Jun 28, 2018 at 3:18 PM, Trey Del Bonis ***@***.***> wrote: Is there a reason we have to pass the &UI everywhere by hand? Is there a way that it could be hidden and inferred when needed? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/LeoTindall/libui-rs/issues/26#issuecomment-401160379>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADI0_VRb7LUo7CoRfakLUwiC-Dh0kBI3ks5uBTorgaJpZM4UogoN> .

-- Leo Tindall leotindall.com | [email protected]

[delbonis]

Perhaps change the design so that when you, for example, call Label::new(), it doesn't actually make any calls to libui, instead giving you an unbound label object. Then take this and go build your whole UI with these unbound object. Then later, you go and instantiate the view by giving it to the actual UI object that would traverse the tree and create everything in one shot. You'd keep track of the bindings to the ui* objects internally, away from the user. And I don't know enough about the internals of libui to know how you'd implement mutating the UI tree, later on though.

Of course this would require a pretty major refactoring so that's annoying. 🤷‍♂️

[NoraCodes]

This is a good idea, and something that I might do once `libui` gets its internal memory management sorted out; at the moment, unfortunately, it's a recipe for having a lot of memory leaks, because controls we create can't be freed manually (i.e. they have toe be bound into a tree and then the tree has to be deinitialized).

…

On Thu, Jun 28, 2018 at 3:46 PM, Trey Del Bonis ***@***.***> wrote: Perhaps change the design so that when you, for example, call Label::new(), it doesn't actually make any calls to libui, instead giving you an unbound label object. Then take this and go build your whole UI with these unbound object. Then later, you go and instantiate the view by giving it to the actual UI object that would traverse the tree and create everything in one shot. You'd keep track of the bindings to the ui* objects internally, away from the user. And I don't know enough about the internals of libui to know how you'd implement mutating the UI tree, later on though. Of course this would require a pretty major refactoring so that's annoying. 🤷‍♂️ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/LeoTindall/libui-rs/issues/26#issuecomment-401168109>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADI0_Z2yMx4ayV9ikm2qOc_MGF4CPbRsks5uBUC6gaJpZM4UogoN> .

-- Leo Tindall leotindall.com | [email protected]

[NoraCodes]

This is like the solution we were discussion to #54 and will likely be solved in the same way.

[tobia]

The UI context reference allows iui to ensure, at compile time, that you your code will not call libui functions prior to initialization, which would be unsound.

That is the only reason? Could this not be done by checking some global flag before calling any C methods and panic if it is not set?

Or rather, if a panic-like behaviour is what you mean by "unsound", then let just that happen. I cannot imagine somebody not calling UI::init() and then complaining about a panic or other crash.

[Inc0n]

I agree with what this comment said about hiding away ctx:&UI, ImGui, i think, does it in a similar way.

A global context is created on ImGui::init().
Whenever a functions that requires the context, it can get the context with ImGui::get_current_context()

[bdamitz]

Just spitballing, perhaps we could create a trait like

trait Bind: UnboundedControl {
    fn bind(&mut self, _ctx: &UI);
}

where control-specific bindings are run for rust data structs impl UnboundedControl. Theoretically this should mean unsafe C code is only called during bind()? This would allow a model like

let mut win = Window::new("Test App", 200, 200, WindowType::NoMenubar);
win.bind(&ui);

Then unbounded controls could be added with recursive calls to bind() by UI and its children with syntax like

ui.add(win);    // would call `bind()` on `win`
// or
ui.add_all([
    Window::new("Test App", 200, 200, WindowType::NoMenubar)
        .set_child(
            Button::new("Button")
                .on_clicked(move |btn| {
                    btn.set_text("Clicked!")
                 }) // Unbounded controls follow a builder pattern -> &mut Self?
        ),
    Window::new(...),
    ...
]);