Store all input Events between updates so that they can be inspected by Widgets

[mitchmindtree]

Right now, Widgets can only check the present state of the Mouse. It would probably be more useful to store each of the input events that have occurred between each update in a single buffer along with methods for quickly filtering through it in useful ways.

This would also allow for fixing #384 .

[bvssvni]

Is it possible to store E: GenericEvent?

I guess this will be a problem if people are calling Conrod with two different types of events.

[bvssvni]

We could map events back to Input and store them in a Vec<Input>.

[mitchmindtree]

@bvssvni yeah I was imagining a Vec<Input> :)

Perhaps in a wrapper type that offers a collection of methods yielding different useful iterators over the kinds of input events?

[bvssvni]

Can we do this in a loop in set_widget? It seems possible to call Widget::update multiple times.

[mitchmindtree]

@bvssvni hmm I'm not sure what you mean?

I think it might be a bit too expensive to call Widget::update multiple times in a loop, as some widgets might have complex updates. Then again, I guess it would hardly ever get called more than once as it would be rare to have more than one or two Input events between updates.

I imagined the Ui would store the Vec<Input> and each time Ui::handle_event is called with an Input, it would add the event to the stack. The Vec<Input> would be reset between updates.

The widgets would receive a view of this Vec<Input> (perhaps via the wrapper type providing helper methods as described in my previous comment) within the UserInput type that is given via the UpdateArgs when Widget::update is called. That way each time a widget's update is called, it just handles the events that happened since its last update.

[bvssvni]

The behavior of a widget should not depend on which partition of events it received. For example, if the widget capturing the mouse is determined in set_widget, then it can't change in Widget::update.

[mitchmindtree]

hmm I'm still not following? The widget that's capturing the mouse is currently determined within the Widget::update, i.e. here.

[bvssvni]

Ok.

[bvssvni]

@mitchmindtree I am trying to get up to speed on the source. Are you on IRC?

[mitchmindtree]

@bvssvni sorry I missed you! I've been busy with work as well as a masters proposal :) I'll try and hang about IRC tonight in case you still want to discuss 👍

[bvssvni]

@mitchmindtree Thanks! Of course you should prioritize your master degree...

[bvssvni]

@mitchmindtree The thing I want to talk about is the details around the event logic. I understand what is happening but not enough to plan changes.

[mitchmindtree]

Closed by #684.