Refactor AppDelegate into a trait #283
Conversation
|
An impl for an empty struct is totally reasonable. The 'should the app delegate have secret state' question is a deep one. I really don't know; the main justification for the previous design was to make this impossible, but I didn't have a good justification for wanting this to be impossible. More and more, lately, one of my main design principles for druid is that we should make it easy for framework users to implement the hacks they need to get their apps working, and a stateful app delegate is another tool in that drawer. |
LiHRaM
force-pushed
the
appdelegate-trait
branch
from
561b6ef to
30a36bd
Compare
druid/src/app_delegate.rs
Outdated
| AppDelegate::new() | ||
| let _ = data; | ||
| let _ = env; | ||
| let _ = ctx; |
There was a problem hiding this comment.
oh, unused warnings? I would annotate this function #[allow(unused)].
There was a problem hiding this comment.
Yeah, I was following the discussion mentioned in #283 (comment), and it seemed to be the most correct solution, but the attribute is also fine with me. 😄
There was a problem hiding this comment.
ah gotcha, missed that comment. We have adopted the pattern of using #[allow] on each function with this problem, so let's just keep doing that. 🤷♂
Also box the AppDelegate inside the function to make it cleaner to call.
LiHRaM
force-pushed
the
appdelegate-trait
branch
from
30a36bd to
7a7a1d0
Compare
|
feel free to merge. :) |
While working on #268, @cmyr and I decided it might be worthwhile to implement
AppDelegateas a trait rather than an object storing closures.This is the initial attempt, and it feels nice and simple.
I implemented the trait for an empty struct in
multiwin, which smells a bit.This approach makes it possible for the AppDelegate to maintain state separately from the data which is passed to it via events, any thoughts on how that could be useful? Otherwise this approach might need some tweaking.