Idea: Window::open() taking &Cell<bool> instead of &mut bool? #758
nyanpasu64
started this conversation in
Ideas
Replies: 2 comments
-
I think a better solution is to have Window return a bool indicating whether or not it is still open. For instance, let mut ok_clicked = false;
let window_response = egui::Window::new("Error").with_close_button(true).show(ctx, |ui| {
ui.label(msg);
if ui.button("OK").clicked() {
ok_clicked = true;
}
});
if ok_clicked || !window_response.is_open {
self.error_dialog = None;
} There is also a half-finished popup API in egui: let popup_id = Id::new("my_popup");
if ctx.memory().is_popup_open(popup_id) {
let mut open = true;
egui::Window::new("Error").open(&mut open).show(ctx, |ui| {
ui.label(msg);
if ui.button("OK").clicked() {
ctx.memory().close_popup(popup_id);
}
});
if !open {
ctx.memory().close_popup(popup_id);
} |
Beta Was this translation helpful? Give feedback.
0 replies
-
Also, my answer on this other issue suggests just not using the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm trying out egui. I'm trying to create an "error message" dialog which can be closed through the title bar's X button, as well as an OK button in the widget. If I'm not mistaken, this is achieved by calling
Window::open()
which modifies a bool by reference, followed byUi::button()
which lets you test if it's clicked. So I tried writing the logic as follows:This works, but for simplicity, I'd like to use the same boolean flag for "close pressed" and "OK pressed". But I can't do this with the current API, because
Window
exclusively borrows the bool passed in until after theshow
closure finishes executing.(What's the recommended way to close a dialog upon X or OK? Two boolean flags?)
Describe the solution you'd like
Perhaps
open
could take&Cell<bool>
. This would allowopen
to change whenadd_contents
is called.I think the current program logic should be correct when modified to take this into account, and it won't introduce logic errors. The value of
open
is only checked once inWindow::show_dyn()
(the function returns if false), and a second time in the function to check whether to show the close button (if it gets set to false in between, no big deal, the close button disappears). ThenTitleBar::ui()
writesfalse
toopen
if clicked. So there's no harm ifadd_contents
(or whatever other function) meddles with the value ofopen
.My concern is that this change, while correct and useful from a user perspective, is altogether too difficult to reason about (due to being more clever than pragmatic) and evolve correctly in the long term, and feels more C++-like than Rust-like due to aliased mutability. This is particularly concerning because
window.rs
is labeled:Additionally,
&Cell<bool>
is more confusing for novice users and awkward to create than&mut bool
(despite being more permissive to the user), possibly making this API harder to use.Describe alternatives you've considered
Leave the API as is.
Beta Was this translation helpful? Give feedback.
All reactions