Suggestion: Make Esc key close dialogs


I.e., make it take the same action as pressing the “close” button.


I still see ESC as escape key, with the result that i still get starnge results because it’s linked to the pause function.

Question is only to what key are we moving the Pause function then ?


The ‘Break|Pause’ key?


Ah, I forgot that Esc still pauses Interface if you’re in HMD mode. (I currently don’t have an HMD with me.) … Interface hogging the Esc and Alt keys I find annoying.

For “pause”, I like the idea of using the Pause/Break key instead. (I wonder if Macs have such a key or equivalent?) Or making Esc to pause work only if no dialog or whatever has focus.

And for “HMD menu”, I’ve often wondered whether the spacebar would be a better key to use. Again, only brings up the menu if no dialog or whatever has focus.


I do not think mac have pause key.
Spacebar, i think the used that in thge early days, and i absolute hate that idea to use the spacebar. Because it’s mabye needed for other things or you get weird results when in wrong window etc.

Also for games spacebar can be used for that.
ESC key with double function ? short press = ESC window etc.
Hold the ESC key longer activate pause ?


I believe Macs have extra function keys where those 3 keys are on a PC, so allocating the spatially-equivalent f-key on a mac may be a suitable compromise?


Note: Ctrl+w seems to work for dismissing many of the common dialogs.

It would be nice if Esc worked too (especially for disruptive popups like Window.alert/confirm/prompt).

A month or two ago I tried prototyping system-wide support for ESC… but immediately ran into edge cases. For example, some dialogs perform cleanup in response to a Cancel button, but don’t seem to handle the or Ctrl+w cases. Is that a bug? I dunno, but between those situations and the overloaded concepts of and “close…” things became rather confusing to try and sort out / test (ie: closed vs. rendered invisible vs. not shown vs. canceled, hidden, destroyed, destroy-if-closed, destroy-if-hidden, etc.).

If anyone is curious I put my work-in-progress Esc changes into a make-esc-close-dialogs branch.

Also Window.qml # L291 is where Ctrl+w gets bound – which seems to be the simplest place to experiment with different key bindings (at least for QML Window-based dialogs). Eg: by adding a case Qt.Key_Escape: ...; break; and if Mac-specific additional keys are needed then maybe wrapped in if (Qt.platform.os === "osx") {...}.


Break/pause keys are the most nonstandard mappings around:

But seriously, the ESC key in virtual worlds implements one of the most useful soft context functions. Destroying it to pause interface is a sad demise to its usefulness. Pausing is a nice thing and I am surprised it is needed for HMD mode since removing your head gear is supposed to pause the avatar (make it go into supplicant/fealty mode). In desktop mode that sort of thing could be done with a menu selection - no need to waste the ESC key.


In desktop mode that sort of thing could be done with a menu selection - no need to waste the ESC key.

Except thst you first need to go in pause mode before you can access the menu’s on you desktop. To dwitch as example back to desktop mode.


No you do not. Menus are always accessible in desktop mode. Did you mean in HMD mode? In HMD mode, to pause just remove your head gear. At least that is how it is supposed to work.


If your in HMD and want to switch to desktop. Or you forgot to switch to desktop before turning hifi and HMD off the next time you need to press enter or soemtimes enter to activate your mouse cursor.

And no, removing the headset never worked to release the mouse cursor so i can move it on the desktop. the controllers keep owning the mouse. until you press ESC. That’s very annoying if you need todo soemthing on your pc anyway and the controllers are activated. Mabye need to check steamVR for other setting ?


That just means the devs never fixed that missing functionality. @philippe said quite some time ago in one of the meet-ups that he expected/desired the HMD to go in and out of desktop mode based on wearing or removing the HMD. And as for the controllers not letting go that too seems like a bug.