Immediate mode interface about conrod HOT 6 CLOSED

@TyOverby is working on an implementation of this in Rust https://github.com/TyOverby/Rust-IUI/

from conrod.

Just watched the mollyrocket vid - super cool!

I did a PR recently with a more classical/imperative style widget system just to get things kicked off with Conrod, but I'd be more than happy to see the direction go more along the lines of Ty's and the immediate mode style :-)

from conrod.

Some interesting discussion of pros and cons here: http://gamedev.stackexchange.com/questions/24103/immediate-gui-yae-or-nay

from conrod.

Some more thoughts:

I'm finding myself struggling to reason about how some of the more complex widgets would work in a practical sense - particularly text-boxes and other widgets that can have much more complex widget states than just Active / Highlighted / Normal for example (like cursor position, text highlighting, etc). All of this state would still have to be stored somewhere (in the UIContext i'm guessing?).

The discussion between immediate and retained seems to largely revolve around where the widget state is stored ("retained" seems to focus on widget structs where "immediate" seems to focus on the UIContext).

How would we get the interactive events (MousePress, MouseMove, etc) into the render loop to be considered by the draw_widget functions so that they can update their state in the UIContext? I'm guessing we could constantly store current mouse/keyboard/controller state in the UIContext to get around this?

In the mollyrocket vid he seems to suggest that there is only ever one active widget at any time (correct me if I'm wrong). Maybe it would be useful to avoid this mindset if we can in case we hope to support multi-touch devices in the future where for example a user might want to move multiple sliders at once? I don't think this should be too tricky to work around though.

Will this style really be more beneficial and elegant as opposed to the classical retained style? I love the idea of not having UI segmented across an "init" section and a "callback" section, though it seems that in trying to solve this with immediate-mode, we just end up with the segmentation being across the UIContext and render-loop instead?

I'm still really keen to see an immediate-mode UI work, though I have a feeling developing this library will take quite a lot of thought to get right. This could just be because I'm so much more familiar with the retained style though :-) I'm going to have a play around with an immediate-mode version of the widget system today and see how it feels :-)

from conrod.

The case with multi touch is important. Storing state inside the widget that you don't care about is a good thing. Usually the appearance does not matter for the event logic, so you want to declare this upfront.

from conrod.

A C/C++ implementation:

https://github.com/ocornut/imgui

from conrod.