Obs-studio: UI: Allow the use of Esc key to quit Settings window

[UserNaem]

Expected Behavior

The Settings window should close, just like any other pop-up window.

Current Behavior

Esc key doesn't do anything.

Steps to Reproduce

1. Open the Settings window
2. Press Esc

[dodgepong]

Should it, though? I don't consider the settings window like any other pop-up window. It contains a lot more inside it than other windows, and accidentally closing the window is potentially more destructive than for other windows. I'm not closed to the idea, but I'd like to see a stronger case put forward as to why it should be done.

[UserNaem]

Every popup window and every settings window everywhere ever closes when you hit Esc, that's the expected behaviour. Obs-classic did it, too. If you want to make sure any modified settings are saved, you can prompt "Settings changed. Save?" with Yes/No/Cancel being the options.

[Hoishin]

Every popup window and every settings window everywhere ever closes when you hit Esc

That's just simply not true.

[jp9000]

If you hit the [x] button in the upper right, you'll notice that the behavior is different from clicking "cancel". When you hit the [x], it will prompt you if you want to save your settings if you modified anything. I think as long as it prompts to save your settings I'm okay with it.

[QwazyWabbitWOS]

The Microsoft design guides recommend the Esc key always closes a dialog box. This has been true for as long as I have been using Windows. (i.e., since 1985) :)
(Yes, I'm really old but I'm not dead yet.)

https://docs.microsoft.com/en-us/windows/win32/uxguide/win-dialog-box

The last bullet point under the heading "Interaction" reads:

Pressing the Esc key always closes an active dialog box. This is true for dialog boxes with Cancel or Close, and even if Cancel has been renamed to Close because the results can no longer be undone.

If changes have been made then the offer to save or discard those changes is highly recommended. Usability recommendations are that there should always be a keyboard method of interfacing as well as a mouse or touchscreen method.

[WizardCM]

I agree this'd be a good change, and would be consistent with Properties, Advanced Audio Properties, Auto-Config, Output Timer, Captions, Custom Browser Docks, About, and Filters. Having it ask "Would you like to save", the same way the [x] does, would be idea.

I'd also like to see this on Interact, Scripts, and Edit Transform.

[Fenrirthviti]

I'd argue that the settings window isn't exactly a "dialog box" though. I don't feel particularly strongly one way or another, just playing devil's advocate here.

[nokkusuu]

Should it, though? I don't consider the settings window like any other pop-up window. It contains a lot more inside it than other windows, and accidentally closing the window is potentially more destructive than for other windows. I'm not closed to the idea, but I'd like to see a stronger case put forward as to why it should be done.

I definitely agree with the above. The point of the settings window isn't to display information, only to be dismissed a few seconds afterwards. It's an integral window with much more of a purpose, just like the main recording/streaming control window.

However, while I personally would find it unnatural, as long as it prompts the user to save and others believe the escape key should close the settings window, couldn't hurt, right? If there were no changes made with nothing to be saved, having the escape key close the settings window could be seen as a workflow improvement, especially in cases where it was opened by accident.

[unknowndomain]

I had a look into this hoping it would be relatively straight forward.

The Settings, Advanced Audio Mixer and Automatic Switcher are all QDialog windows which mandatorily exhibit close behaviour when you press escape.

In other words this seems more like a bug because I cannot find any code that deliberately disables this anywhere, nor can I see anywhere that specifically implements this feature (as you would expect its default behaviour).

I searched everywhere for Qt::Key_Escape and variations thereof and could only find reference in one place which was within obs-app.cpp line 181, inside CreateShortcutFilter() which is used in settings but is only effective when entering a hotkey.

Disabling this code and building did not fix the issue so that rules out any conflict with this event filter.

I've hit a wall on this, perhaps others will have luck.

[Bennik2000]

The problem with this, as I understand, is the call to App()->DisableHotkeys(); in window-basic-settings.cpp Line 797.
This disables all hotkeys in the application, which is necessary to prevent unwanted actions while reconfiguring the hotkeys.
However, I figured out a way to listen to the escape key event and show a confirmation window when the escape key is pressed.

[Fenrirthviti]

Fixed in #2916