-
-
Notifications
You must be signed in to change notification settings - Fork 175
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
Adapt to glib::Inhibit removal #1414
Conversation
fef61ff
to
cf3885c
Compare
@@ -41,7 +40,7 @@ fn build_ui(application: >k::Application) { | |||
if let Some(application) = window.application() { | |||
application.remove_window(window); | |||
} | |||
Inhibit(false) | |||
ControlFlow::Break |
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.
Shouldn't this be ControlFlow::Continue
?
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.
Very possibly, I will check tomorrow
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.
After looking at related changes I may say the change is correct.
But wording seems misleading. "Inhibit" is closer to "Break" (or "Stop" or "Prevent").
The GTK doc of a signal close-request
says:
Return value
Type: gboolean
TRUE to stop other handlers from being invoked for the signal.
It seems natural to use Break
to represent Inhibit(true)
and Continue
to represent Inhibit(false)
.
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.
Would you mind opening an issue about 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.
Depends on gtk-rs/gtk-rs-core#1126