Check FLAG_POPUP to close an AcceptDialog when parent is focused

[ItsNL]

Fix #79150

The close_on_escape property was used to be able to close an AcceptDialog by pressing the Esc key, but it was also checked to close when the parent was focused, meaning it had lost the focus.

With this pull request instead of checking if close_on_escape is true to close automatically when the parent is focused (For example clicking outside of the dialog), it will check if popup_window is true.

Now dialogue_close_on_escape only affects if pressing the Esc key will close the dialog.

Here is a video showing the change:

close_on_unfocused.test.-.fix.79150.-.godot.mp4

Note: When using popup_window you will need that exclusive is false so that it works. exclusive as true blocks all input that is outside the dialog.
Note 2: When only using dialog_close_on_escape clicking outside will make the dialog's focus be lost and so using Esc won't work until the dialog has the focus again.

[Sauermann]

I was rather thinking along the lines of

diff --git a/scene/gui/dialogs.cpp b/scene/gui/dialogs.cpp
index 0860bf3968..5865e06ec9 100644
--- a/scene/gui/dialogs.cpp
+++ b/scene/gui/dialogs.cpp
@@ -45,7 +45,7 @@ void AcceptDialog::_input_from_window(const Ref<InputEvent> &p_event) {
 }
 
 void AcceptDialog::_parent_focused() {
-       if (close_on_escape && !is_exclusive()) {
+       if (!is_exclusive()) {
                _cancel_pressed();
        }
 }

I am not sure, if there is a use-case supporting close_on_unfocused.

[ItsNL]

Your option uses exclusive as your way to decide if the dialog will close or not when clicking outside. But, when enabling exclusive you can't interact with the rest of the interface.
So, a use-case of close_on_unfocused would be having it off, but being able to have the entire UI accessible without having to close the dialog first or closing it automatically. With the option of still being able to close it using Esc (if wanted).
In conclusion, with that option, a user has to decide whether they allow clicking outside of the dialog to close it or not allow interacting with any other UI at all.

[bruvzg]

It won't work with native windows when switching focus to the other app, so the property name can be misleading. For native windows, the same behavior is handled by FLAG_POPUP, so it probably should check it instead of adding a new property.

[ItsNL]

I have the changes ready using FLAG_POPUP and it works fine. Should I create another Pull Request and close this one? Because now it has nothing to do with this Pull Request.

[KoBeWi]

You can change commit message and title. No need to make new PR.

[ItsNL]

With the new way of using FLAG_POPUP, what should I do with its description?
Right now it says:

If [code]true[/code], the [Window] will be considered a popup. Popups are sub-windows that don't show as separate windows in system's window manager's window list and will send close request when anything is clicked outside of them (unless [member exclusive] is enabled).
[b]Note:[/b] This property only works with native windows.

I don't think I have to change it because the behavior described doesn't involve the change.

[Sauermann]

I can confirm, that this solves the linked issue for me.

After a few tests, I believe, that the note can be removed:

[b]Note:[/b] This property only works with native windows.

The description fits with the behavior of non-native windows.

[ItsNL]

Ok. I've deleted the note now.

[Sauermann]

Have tested it successfully with my MRP in the linked issue.

[akien-mga]

Thanks!