UIContext #94
UIContext #94
Conversation
…ethods and consts
AaronM04
force-pushed
the
aaron/uicontext
branch
from
64f5e7a
to
ac8aeef
Compare
Probably a good idea since 83 changes how the underlying data is structured. No additional comments on my part for this PR. Great job with the clean up so far. 👍 |
This avoids potential panics in the handlers when they expect a field to be Some(..) when it's actually None because we forgot to put it in.
|
@Manghi ready for your final review! 🚀 |
|
I've been following your changes along the way and they looks awesome! I'm going to play around with it tomorrow and then do a final general review. |
| // handle forwarded events | ||
| loop { | ||
| let mut events = vec![]; | ||
| std::mem::swap(&mut events, &mut self.$handler_data_field.forwarded_events); | ||
| if events.len() == 0 { | ||
| break; | ||
| } | ||
|
|
||
| for event in events { | ||
| if let Some(handler_vec) = handlers.get_mut(&event.what) { | ||
| // call each handler for this event type, until a Handled is returned | ||
| for hdlr in handler_vec { | ||
| let handled = hdlr(self, uictx, &event)?; | ||
| if handled == Handled { | ||
| break; | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } |
| #[test] | ||
| fn test_compile_fail_double_mut_borrow() { |
There was a problem hiding this comment.
Will this test ever be needed?
There was a problem hiding this comment.
Uncommenting it causes a compile failure -- if it doesn't, something got screwed up with borrowing, and undefined behavior could result.
I don't know of a way to have a test that verifies it can't compile, so I'm just leaving it commented.
There was a problem hiding this comment.
BTW if you find a way to have a test with code that only passes if it fails to compile, that would be amazing! 😁
There was a problem hiding this comment.
This looks promising: https://crates.io/crates/compiletest_rs
but I think it's overkill for this one test. Fine with leaving it as is.
|
Github lost what the Bump comment was about. |
OK I think it's coming back to me -- you had concerns about the potential for infinite loops when handling forwarded events. I think we just have to be aware of that possibility when writing our handlers. |
This adds a UIContext so that widget logic can happen within the widget definition rather than in client.rs.