-
Notifications
You must be signed in to change notification settings - Fork 95
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
Escape key closes windows #1461
Comments
Actually it's only default with Qt, I personally never succeed Esc-quiting when using wx (by default) |
I believe this is an issue with event propagation: The esc-to-close works when the bottom bar (with the buttons) is focused, but not when any other part of the window is focused. The diff --git a/traitsui/wx/toolkit.py b/traitsui/wx/toolkit.py
index bd867e7a..3ac352bb 100644
--- a/traitsui/wx/toolkit.py
+++ b/traitsui/wx/toolkit.py
@@ -410,6 +410,8 @@ class GUIToolkit(Toolkit):
"""Indicates that an event should continue to be processed by the
toolkit.
"""
+ if not event.ShouldPropagate():
+ event.ResumePropagation(wx.EVENT_PROPAGATE_MAX)
event.Skip()
def destroy_control(self, control):
diff --git a/traitsui/wx/ui_live.py b/traitsui/wx/ui_live.py
index ed48f19f..768e5fb6 100644
--- a/traitsui/wx/ui_live.py
+++ b/traitsui/wx/ui_live.py
@@ -336,6 +336,8 @@ class LiveWindow(BaseDialog):
"""Handles the user pressing the Escape key."""
if event.GetKeyCode() == 0x1B:
self._on_close_page(event)
+ else:
+ event.Skip()
def _on_cancel(self, event):
"""Handles a request to cancel all changes.""" EDIT: Maybe a better approach is to use |
The default behaviour of a TraitsUI window is that the escape key closes the window with the same behaviour as clicking the close titlebar icon. This is probably OK for modal dialogs, but is not good behaviour for things which are intended to be more long-lived (eg. project or document style windows).
Currently this is fairly hard-coded behaviour; there are no view-level options to turn it on or off. It can be worked around with a "do nothing" keybinding for the escape key, but the fix is not obvious and may have other side-effects.
Probably the best behaviour would be to remove the current hard-coded behaviour, and add default keybindings for escape that replicate the existing behaviour. Users would then be able to override using a different set of keybindings.
The text was updated successfully, but these errors were encountered: