Tell between menu item click and accelerator keypress

wxPython Users
1

Is there any way to differentiate between a menu item triggered using
the keyboard, and the same item triggered by the accelerator key? In
the following example, I can't find anything that indicates any
difference in the event reported to OnMenuSelected when I click on the
item as compared to hitting Ctrl-T.

Maybe it's not possible to determine within the bounds of wx's
cross-platform nature??? It might be that we must all keypresses
ourselves if we need to know how the event was triggered.

Thanks,

Rob

menu_triggered.py (1.08 KB)

2

Why do you want to know?

···

On 10/8/07, Rob McMullen <rob.mcmullen@gmail.com> wrote:

Is there any way to differentiate between a menu item triggered using
the keyboard, and the same item triggered by the accelerator key? In
the following example, I can't find anything that indicates any
difference in the event reported to OnMenuSelected when I click on the
item as compared to hitting Ctrl-T.

Maybe it's not possible to determine within the bounds of wx's
cross-platform nature??? It might be that we must all keypresses
ourselves if we need to know how the event was triggered.

3

To be able to present a different ui (i.e. keyboard-driven) if the
user triggers the event via the keyboard. Emacs gives you a file
dialog if you select Open from the file menu, but uses the minibuffer
if you hit C-X C-F.

Obviously I can process all keyboard commands myself, I just want to
know if I *must* do that. The aesthetic side-effect of processing
keystrokes yourself is that you lose the nice right-aligned
accelerator labels in the menus if you don't supply an accelerator
key. So, it would be nice to keep the right aligned accelerator label
AND still be able to differentiate between keyboard and mouse
activation.

Rob

···

On 10/8/07, Chris Mellon <arkanes@gmail.com> wrote:

On 10/8/07, Rob McMullen <rob.mcmullen@gmail.com> wrote:
> Is there any way to differentiate between a menu item triggered using
> the keyboard, and the same item triggered by the accelerator key? In
> the following example, I can't find anything that indicates any
> difference in the event reported to OnMenuSelected when I click on the
> item as compared to hitting Ctrl-T.
>
> Maybe it's not possible to determine within the bounds of wx's
> cross-platform nature??? It might be that we must all keypresses
> ourselves if we need to know how the event was triggered.
>

Why do you want to know?

4

> > Is there any way to differentiate between a menu item triggered using
> > the keyboard, and the same item triggered by the accelerator key? In
> > the following example, I can't find anything that indicates any
> > difference in the event reported to OnMenuSelected when I click on the
> > item as compared to hitting Ctrl-T.
> >
> > Maybe it's not possible to determine within the bounds of wx's
> > cross-platform nature??? It might be that we must all keypresses
> > ourselves if we need to know how the event was triggered.
> >
>
> Why do you want to know?

To be able to present a different ui (i.e. keyboard-driven) if the
user triggers the event via the keyboard. Emacs gives you a file
dialog if you select Open from the file menu, but uses the minibuffer
if you hit C-X C-F.

These are obviously different commands then. If the UI presented isn't
the same, then the menu shouldn't show the same hotkey.

Use a wxAcceleratorTable for your keyboard shortcuts, with different
IDs than the menu events.

···

On 10/8/07, Rob McMullen <rob.mcmullen@gmail.com> wrote:

On 10/8/07, Chris Mellon <arkanes@gmail.com> wrote:
> On 10/8/07, Rob McMullen <rob.mcmullen@gmail.com> wrote:

Obviously I can process all keyboard commands myself, I just want to
know if I *must* do that. The aesthetic side-effect of processing
keystrokes yourself is that you lose the nice right-aligned
accelerator labels in the menus if you don't supply an accelerator
key. So, it would be nice to keep the right aligned accelerator label
AND still be able to differentiate between keyboard and mouse
activation.

Rob

5

> To be able to present a different ui (i.e. keyboard-driven) if the
> user triggers the event via the keyboard. Emacs gives you a file
> dialog if you select Open from the file menu, but uses the minibuffer
> if you hit C-X C-F.

These are obviously different commands then. If the UI presented isn't
the same, then the menu shouldn't show the same hotkey.

You're not an emacs user, and so from that perspective I do see your
point. In emacs, it *is* the same command, but has different
presentations. But, hearing your confusion, I may include an option
to operate as a non-emacs user might expect.

Use a wxAcceleratorTable for your keyboard shortcuts, with different
IDs than the menu events.

Thanks, that's a useful tidbit. I hadn't run across the
wxAcceleratorTable before.

···

On 10/8/07, Chris Mellon <arkanes@gmail.com> wrote:

On 10/8/07, Rob McMullen <rob.mcmullen@gmail.com> wrote:

6

> > To be able to present a different ui (i.e. keyboard-driven) if the
> > user triggers the event via the keyboard. Emacs gives you a file
> > dialog if you select Open from the file menu, but uses the minibuffer
> > if you hit C-X C-F.
>
> These are obviously different commands then. If the UI presented isn't
> the same, then the menu shouldn't show the same hotkey.

You're not an emacs user, and so from that perspective I do see your
point. In emacs, it *is* the same command, but has different
presentations. But, hearing your confusion, I may include an option
to operate as a non-emacs user might expect.

It's not the same command, and it's not the same command in emacs. It
does *a different thing*. That makes it a different command.

It doesn't matter what you dispatch on to tell the difference - emacs
might dispatch on context, while a wxPython implementation would
dispatch based on the command ID, but you're still dispatching on
something, and you're still doing different things.

A similar difference can be found in "Find..." vs "Find Next". "Find
Next" will either search to the next instance of the search term, or
(if there is no search term) it will open the "Find" dialog so you can
enter one. If there's no search term, the two commands behave
identically and you might be confused into thinking they're the same
thing - but they aren't. They're two distinct commands, because the
second has different behavior and dispatches based on different
context.

> Use a wxAcceleratorTable for your keyboard shortcuts, with different
> IDs than the menu events.

Thanks, that's a useful tidbit. I hadn't run across the
wxAcceleratorTable before.

If you're specifically trying to implement emacs style keybindings,
there was a post a while ago (maybe a year?) with a custom keybinding
scheme that managed 2-stage keybindings. If I can find the post I'll
reply with a link.

···

On 10/8/07, Rob McMullen <rob.mcmullen@gmail.com> wrote:

On 10/8/07, Chris Mellon <arkanes@gmail.com> wrote:
> On 10/8/07, Rob McMullen <rob.mcmullen@gmail.com> wrote:

7

Chris Mellon wrote:

If you're specifically trying to implement emacs style keybindings,
there was a post a while ago (maybe a year?) with a custom keybinding
scheme that managed 2-stage keybindings. If I can find the post I'll
reply with a link.

You're probably thinking of this recipe in the wiki: Using Multi-key Shortcuts - wxPyWiki

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

8

You can save yourself the trouble of looking for that -- see

http://wiki.wxpython.org/EmacsStyleKeybindings

which I wrote as an extension of Josiah Carlson's original

http://wiki.wxpython.org/Using_Multi-key_Shortcuts

···

On 10/8/07, Chris Mellon <arkanes@gmail.com> wrote:

If you're specifically trying to implement emacs style keybindings,
there was a post a while ago (maybe a year?) with a custom keybinding
scheme that managed 2-stage keybindings. If I can find the post I'll
reply with a link.

9

The one I thought I saw worked by swapping out wxAcceleratorTables
according to state, but I can't find it now, so I may have just seen
Josiah's and thought about an alternate implementation.

···

On 10/8/07, Rob McMullen <rob.mcmullen@gmail.com> wrote:

On 10/8/07, Chris Mellon <arkanes@gmail.com> wrote:
> If you're specifically trying to implement emacs style keybindings,
> there was a post a while ago (maybe a year?) with a custom keybinding
> scheme that managed 2-stage keybindings. If I can find the post I'll
> reply with a link.

You can save yourself the trouble of looking for that -- see

EmacsStyleKeybindings - wxPyWiki

which I wrote as an extension of Josiah Carlson's original

Using Multi-key Shortcuts - wxPyWiki

10

Rob McMullen wrote:

But, hearing your confusion, I may include an option
to operate as a non-emacs user might expect.

this is a good point, Rob. It's going to be a bit of a struggle, but keeping the power of Emacs, while allowing a "modern" interface is going to be a trick.

Even though I am an Emacs user, I don't want to be using Emacs-style key bindings in my editor -- I want to use binding that match all the other pas I run as much as possible.

IIUC, you're building Peppy to support multiple key bindings option, in which case, I think Chris is right -- OpenFileDialog and OpenFileWith MiniBuffer are two different actions, and while some folks would want one bound to a key binding, and the other a menu, others will want the key binding and menu to both bring up a Dialog.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

11

Rob McMullen wrote:
> But, hearing your confusion, I may include an option
> to operate as a non-emacs user might expect.

this is a good point, Rob. It's going to be a bit of a struggle, but
keeping the power of Emacs, while allowing a "modern" interface is going
to be a trick.

I did rethink my assumption and have already coded the emacs
gui/keyboard split personality as two separate actions. Not having
to check for this special case allowed me to simplify the code. It's
more of the spirit of emacs that I was going for anyway, so I don't
have to duplicate its every last detail if it makes more sense some
other way.

Even though I am an Emacs user, I don't want to be using Emacs-style key
bindings in my editor -- I want to use binding that match all the other
pas I run as much as possible.

OTOH, I happen to like the emacs keybindings. But just because I
think it's more useful for C-S to mean search than save because I use
search so much more often than save doesn't mean that others think
like me. The point is that users should be able to define their own
keybindings if they don't like the already-built-in windows and emacs
style. (I want to have Mac-style bindings built in at some point as
well, along with a gui to change keybindings in addition to the
current ini-style file).

Rob

···

On 10/9/07, Christopher Barker <Chris.Barker@noaa.gov> wrote:

12

Rob McMullen wrote:

Even though I am an Emacs user, I don't want to be using Emacs-style key
bindings in my editor -- I want to use binding that match all the other
pas I run as much as possible.

OTOH, I happen to like the emacs keybindings.

Exactly -- my point was that you really want to support both.

users should be able to define their own
keybindings if they don't like the already-built-in windows and emacs
style.

Bingo! Though I think having the obvious ones available out of the box is critical.

By the way, I have no personal interest, but does your framework support vi-style bindings? That's a whole different ball of wax!

> (I want to have Mac-style bindings built in at some point as

well

I'll help with that -- they are pretty similar to the Windows ones for the most part -- at least if wx maps "control" to "command" for you. though it's a bit odd -- as OS-X has both command and control!

> along with a gui to change keybindings in addition to the

current ini-style file).

That'd be nice, but ini files are OK to.

-CHB

···

On 10/9/07, Christopher Barker <Chris.Barker@noaa.gov> wrote:

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

13

Christopher Barker wrote:

IIUC, you're building Peppy to support multiple key bindings option, in which case, I think Chris is right -- OpenFileDialog and OpenFileWith MiniBuffer are two different actions, and while some folks would want one bound to a key binding, and the other a menu, others will want the key binding and menu to both bring up a Dialog.

This has been an interesting discussion for me. From the outside, as a user, I think of "open file" as a single operation, which I can invoke in two different ways. It makes sense to me that, when I use a keystroke to initiate the operation, the subsequent interaction to get the file name should happen in a "keyboard-friendly" manner, so I don't have to reach for the mouse to complete the operation. Similarly, if I used a mouse to choose a menu item, the interaction should be done via a mouse-oriented interface.

That said, it's both emacsish and generally sensible to have all operations bound to actions through a user-changeable mechanism.
Folks coming from traditional GUI interfaces might not want to be bothered with a minibuffer at all.

···

--
Don Dwiggins
Advanced Publishing Technology

14

Christopher Barker wrote:

Rob McMullen wrote:

> (I want to have Mac-style bindings built in at some point as

well

I'll help with that -- they are pretty similar to the Windows ones for the most part -- at least if wx maps "control" to "command" for you.

It does if you use things like CmdDown() instead of ControlDown() and MetaDown().

though it's a bit odd -- as OS-X has both command and control!

I currently have my Emacs settings on Mac using the Ctrl key for all the Emacsy bindings and the custom bindings I've done in my .emacs and use on all platforms, and the Cmd key is set to match all the standard OS X key bindings as much as possible. This way if I switch from some Mac app to Emacs and my fingers are still used to the "The Mac Way" then it works, and if I switch from another platform to Emacs on the Mac and my fingers are still in CUA mode with the Ctrl key then it also works.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

15

OT, but what the heck...

Robin Dunn wrote:

Christopher Barker wrote:

though it's a bit odd -- as OS-X has both command and control!

I currently have my Emacs settings on Mac using the Ctrl key for all the Emacsy bindings and the custom bindings I've done in my .emacs and use on all platforms, and the Cmd key is set to match all the standard OS X key bindings as much as possible. This way if I switch from some Mac app to Emacs and my fingers are still used to the "The Mac Way" then it works, and if I switch from another platform to Emacs on the Mac and my fingers are still in CUA mode with the Ctrl key then it also works.

As most "standard" GUI apps use the Command Key on the Mac and control on windows and Linux (Thunderbird, Firefox, etc, etc), I kept getting confused and trying to use ctrl+c on the mac, when I meant cmd+c. So I mapped the ctrl key to mean "command" on the Mac. However there are programs (unix command line stuff in particular) that need the control key, so, since the CapLock key is evil, I've mapped CapsLock to ctrl on all my machines -- Linux, Mac and Windows. It works for me!

-Chris

PS: I recommend everyone re-maps their CapsLock key anyway!

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov