-
Notifications
You must be signed in to change notification settings - Fork 567
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds a hook for intercepting close requests. #1118
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The missing changlog entry and one comment aside, this looks good, thanks.
druid/src/win_handler.rs
Outdated
/// Returns `false` if the command was handled. | ||
fn dispatch_cmd(&mut self, target: Target, cmd: Command) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a bit backwards to me, I would expect true
to indicate handled. This would also be in line with Window::event
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree and so I've changed it, but note that delegate_cmd
and AppDelegate::command
use the opposite convention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, maybe we could define
type Handled = bool;
type Propagate = bool;
wonder if there is good prior art / reference for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's worth having a enum { Handled, NotHandled}
? Then there's no ambiguity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that would be the "cleanest" solution I guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to do a PR for that or should I do it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this usage of enums/prefer it over bools,
I know at least petgraph uses these types of enums for edge directions, if people want to see a code base where that patterns been used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could probably take a stab at a PR on the weekend, but if you've got time before that then go ahead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I'll take care of it then.
In druid-shell, a close request from the system will result in a call to `WinHandler::request_close` instead of just immediately destroying the window. In druid, CLOSE_WINDOW commands are passed to the AppDelegate and down the widget tree. Only if they are unhandled does the window get closed.
In druid-shell, a close request from the system will result in a call
to
WinHandler::request_close
instead of just immediately destroyingthe window.
In druid, CLOSE_WINDOW commands are passed to the AppDelegate and down
the widget tree. Only if they are unhandled does the window get closed.
Edit: so far the druid-shell part is only implemented for gtk. Other platforms still close the window unconditionally.