Callbacks WIP #106
Callbacks WIP #106
Conversation
| tabs.status_bar.borrow_mut().handle_baseline_ned(msg); | ||
| }); | ||
|
|
||
| link.register_cb(|msg: Dops| { |
There was a problem hiding this comment.
we could also move these calls to their respective tab's new function and store a link in each tab as well, like the current console. just trying to keep the changes small
There was a problem hiding this comment.
I guess I could see value both ways. Keeping things here makes it easier to see what all needs what in one spot instead of digging through each file. So adding new messages what have you could be easier in the future.
| msg_sender: types::MsgSender, | ||
| ) -> Self { | ||
| Self { | ||
| main: MainTab::new(shared_state.clone(), client_sender.clone()).into(), |
There was a problem hiding this comment.
With these changes it might be worth renaming this "MainTab" to something more appropriate. That being said I filed a ticket recently to try and rework some of the logic for logging directory which will hit the MainTab quite a bit. So probably could hold off. Still don't know what it should be called though :D
There was a problem hiding this comment.
Yeah I was thinking the same thing. Basically what I did to the main tab was break out any of the functionality that reached into sub-tabs and moved that into the shared state. Which ended up being the three csv log files. But yeah not really sure what to call it now. Maybe we could just put everything into shared state? At this point it seems to pretty much just be global state like are we logging, what was the last gps time etc
There was a problem hiding this comment.
Thats not a bad idea. SharedState is probably at a point where it could be put into its own file. Would reduce the size of types.rs a bit too which is beyond needed.
There was a problem hiding this comment.
Naming suggestion: App, AppState or maybe AppContext (instead of SharedState)
| @@ -1,16 +1,16 @@ | |||
| use capnp::message::Builder; | |||
| use std::collections::HashMap; | |||
There was a problem hiding this comment.
Maybe this was a mistake?
There was a problem hiding this comment.
Oh I think I just reordered the imports std -> third_party -> crate. we're a little bit all over the place with that (not that it particularity matters)
| }; | ||
|
|
||
| struct Tabs<'a, S: types::CapnProtoSender> { | ||
| pub main: Mutex<MainTab<S>>, |
There was a problem hiding this comment.
Alas we do have to use a mutex instead of refcell. This is because there are a few places where we move a Link to a separate thread to read + dispatch messages. I think there is probably a way around it but not 100% sure
notoriaga
force-pushed
the
steve/callbacks
branch
from
9d4bf86 to
0f65b23
Compare
| fn test_dispatcher() { | ||
| let mut d = Link::new(); | ||
| let mut c = Counter { count: 0 }; | ||
| d.register_cb(|obs| c.obs(obs)); |
There was a problem hiding this comment.
Super cool to be able to register a callback based on the type of the function parameter!
No description provided.