multistroke keyboard shortcuts?

wxPython Users
1

Doh!

You caught me guessing. I am taking a wild guess but i think it may be possible. The hard part is figuring out how to catch a second key stroke. I haven't played with STC, so I don't know it's capabilities at all. It may have a feature for this, but based on the editors implemented with it, it seems beyond it's scope.

I don't think the accelerator table ever overrides menu acclerator keys. Infact as far as I understand it, they are more or less the same thing, with the exception that wx populates the table automatically with the menuing syntax.

If I were to tackel the concept, I'd might set up an accelerator entry (not too hard but gets a little messy quick). Think you'll need a control to catch 2ndary keystrokes and get shifty with focus to make it seemless. That's kinda what emacs does with the command window at the bottom. Then usher keystrokes to whatever routine.

For key customizations, you'll need to a lookup tables/mappings. Hardwired is okay, but not what ppl generally wish for.

Here's a hardwired one i used in a picture viewer:

         self.aTable = wx.AcceleratorTable([
             (wx.ACCEL_ALT, ord('X'), self.controls.exitPb.GetId()),
             (wx.ACCEL_NORMAL, ord('X'), self.controls.exitPb.GetId()),
             (wx.ACCEL_NORMAL, wx.WXK_ESCAPE, self.controls.exitPb.GetId()),

             (wx.ACCEL_NORMAL, wx.WXK_UP, self.controls.prevPb.GetId()),
             (wx.ACCEL_NORMAL, wx.WXK_LEFT, self.controls.prevPb.GetId()),
             (wx.ACCEL_ALT, ord('P'), self.controls.prevPb.GetId()),
             (wx.ACCEL_NORMAL, ord('P'), self.controls.prevPb.GetId()),
             (wx.ACCEL_NORMAL, wx.WXK_BACK, self.controls.prevPb.GetId()),

             (wx.ACCEL_NORMAL, wx.WXK_DOWN, self.controls.nextPb.GetId()),
             (wx.ACCEL_NORMAL, wx.WXK_RIGHT, self.controls.nextPb.GetId()),
             (wx.ACCEL_ALT, ord('N'), self.controls.nextPb.GetId()),
             (wx.ACCEL_NORMAL, ord('N'), self.controls.nextPb.GetId()),
             (wx.ACCEL_NORMAL, wx.WXK_SPACE, self.controls.nextPb.GetId()),

             (wx.ACCEL_ALT, ord('B'), self.controls.direction.GetId()),
             (wx.ACCEL_NORMAL, ord('B'), self.controls.direction.GetId()),

             (wx.ACCEL_ALT, ord('A'), self.controls.pause.GetId()),
             (wx.ACCEL_NORMAL, ord('A'), self.controls.pause.GetId()),

             (wx.ACCEL_ALT, ord('E'), self.controls.edit.GetId()),
             (wx.ACCEL_NORMAL, ord('E'), self.controls.edit.GetId()),
             ])
         #I attached same accelerators to two frames (self and controls)
         self.SetAcceleratorTable(self.aTable)
         self.controls.SetAcceleratorTable(self.aTable)

E. A. Tacao wrote:

···

Saturday, November 12, 2005, 9:56:24 PM, Chris Mellon wrote:

On 11/11/05, Joe Brown <joebrown@rclooke.com> wrote:

You're looking for a meta-key type functinality. I do not believe
this is possible in an "automatic" type fashion.

I'm also interested on this subject because thought perhaps I could
try to implement such funcionality in Metamenus.

I can confirm that it is not, but you may be able to implement it
fairly simply by using wxAcceleratorTable and adding/removing
enteries as you change states.

What should I do to add/remove AcceleratorTable entries? I looked at
the docs but I couldn't find something like "AddEntry" or
"RemoveEntry".

Or perhaps (I've seen meta-key implementations that work both ways)
by simply swapping out the accelerator tables entirely, and having 1
per state.

If you're on an app with a menubar, swapping out the accelerator
tables entirely means that the menubar should temporarily "forget" the
accelerators previously assigned, right? I couldn't find a way to do
that -- tried to set a new accelerator table but the previous
accelerators still work.

-- tacao

No bits were harmed during the making of this e-mail.

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

2

Monday, November 21, 2005, 1:14:10 PM, Joe Brown wrote:

Doh!

You caught me guessing. I am taking a wild guess but i think it may
be possible. The hard part is figuring out how to catch a second key
stroke. I haven't played with STC, so I don't know it's capabilities
at all. It may have a feature for this, but based on the editors
implemented with it, it seems beyond it's scope.

I don't think the accelerator table ever overrides menu acclerator
keys. Infact as far as I understand it, they are more or less the
same thing, with the exception that wx populates the table
automatically with the menuing syntax.

Yes, I agree.

If I were to tackel the concept, I'd might set up an accelerator
entry (not too hard but gets a little messy quick). Think you'll
need a control to catch 2ndary keystrokes and get shifty with focus
to make it seemless. That's kinda what emacs does with the command
window at the bottom. Then usher keystrokes to whatever routine.

It sounds good, I'll try to experiment on it, but it seems that one
will always need a control showing on screen only to get the secondary
keystrokes.

An issue that comes to mind is related to the menu events. Suppose you
want a <Ctrl>+<C> shortcut available under the "&Copy" command on a
menubar. If you do this, there's no way to use <Ctrl>+<C> neither as
primary nor as a secondary keystroke for any other command, as it will
always be caught by the menubar. Is that the expected behavior, using
meta-keys all over the app or don't using them anyway? What would be
the best of both worlds?

Hm.. I'm just wondering that perhaps swapping the whole menubar would
help. Don't know what wxPython will think of it, though. 8^)

-- tacao

No bits were harmed during the making of this e-mail.

3

Okay,

To avoid conflict of menu interests, you could bind the meta-keys <esc>, C-x, C-c and/or C-h to expose a secondary (menu-less) frame. Don't know if you can override the default behaviour of C-c tho. On windows it's already assigned the copy even w/out a menu.

-Joe

E. A. Tacao wrote:

···

An issue that comes to mind is related to the menu events. Suppose you
want a <Ctrl>+<C> shortcut available under the "&Copy" command on a
menubar. If you do this, there's no way to use <Ctrl>+<C> neither as
primary nor as a secondary keystroke for any other command, as it will
always be caught by the menubar. Is that the expected behavior, using
meta-keys all over the app or don't using them anyway? What would be
the best of both worlds?

Hm.. I'm just wondering that perhaps swapping the whole menubar would
help. Don't know what wxPython will think of it, though. 8^)

-- tacao

No bits were harmed during the making of this e-mail.

4

Because people have been having issues with this, I went ahead and
hacked up a sample which allows for unlimited level keyboard shortcuts
with or without menus.

It is available in the Python Cookbook as:
    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/457407

The sample application handles the combination Ctrl+Y Alt+3 Shift+B, and
should handle just about anything else you want to throw at it (I use
some of the underlying menu handling code in PyPE (http://pype.sf.net),
which this borrows from).

- Josiah

···

Joe Brown <joebrown@rclooke.com> wrote:

Okay,

To avoid conflict of menu interests, you could bind the meta-keys <esc>,
C-x, C-c and/or C-h to expose a secondary (menu-less) frame. Don't know
if you can override the default behaviour of C-c tho. On windows it's
already assigned the copy even w/out a menu.

-Joe

E. A. Tacao wrote:
> An issue that comes to mind is related to the menu events. Suppose you
> want a <Ctrl>+<C> shortcut available under the "&Copy" command on a
> menubar. If you do this, there's no way to use <Ctrl>+<C> neither as
> primary nor as a secondary keystroke for any other command, as it will
> always be caught by the menubar. Is that the expected behavior, using
> meta-keys all over the app or don't using them anyway? What would be
> the best of both worlds?
>
> Hm.. I'm just wondering that perhaps swapping the whole menubar would
> help. Don't know what wxPython will think of it, though. 8^)
>
> -- tacao
>
> No bits were harmed during the making of this e-mail.

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

5

Joe,

This looks very cool.

Josiah Carlson wrote:

Because people have been having issues with this, I went ahead and
hacked up a sample which allows for unlimited level keyboard shortcuts
with or without menus.

It is available in the Python Cookbook as:
    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/457407

Please put it in the wxPython Wiki:

http://wiki.wxpython.org/

Folks will be more likely to find it there.

Thanks,
-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

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

6

Joe,

This looks very cool.

I'm surprised no one had written it before. It took me maybe 30 minutes
to put together.

Josiah Carlson wrote:
> Because people have been having issues with this, I went ahead and
> hacked up a sample which allows for unlimited level keyboard shortcuts
> with or without menus.
>
> It is available in the Python Cookbook as:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/457407

Please put it in the wxPython Wiki:

http://wiki.wxpython.org/

Folks will be more likely to find it there.

You must be joking. The only thing I can ever find in the cookbook is
the "hello world" application.

If you know of a good/proper place to put it, let me know, because I
wouldn't know where to start.

- Josiah

···

"Chris Barker" <Chris.Barker@noaa.gov> wrote:

7

Josiah Carlson wrote:

Please put it in the wxPython Wiki:

http://wiki.wxpython.org/

Folks will be more likely to find it there.

You must be joking. The only thing I can ever find in the cookbook is
the "hello world" application.

I use the search, it works for me. However, your point is well taken, it isn't well organized. However, for wxPython stuff, that's where people look. It never dawned on me to look in the ActiveState cookbook for wxPython-specific stuff.

If you know of a good/proper place to put it, let me know, because I
wouldn't know where to start.

You could start by re-organizing the Wiki :wink:

or, baring that, put it here:

http://wiki.wxpython.org/index.cgi/RecipesEvents

Not ideal, but there is a CharacterCode page there.

-Chris

···

"Chris Barker" <Chris.Barker@noaa.gov> wrote:

--
Christopher Barker, Ph.D.
Oceanographer

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

8

Tuesday, November 22, 2005, 3:52:42 AM, Josiah Carlson wrote:

Because people have been having issues with this, I went ahead and
hacked up a sample which allows for unlimited level keyboard
shortcuts with or without menus.

It is available in the Python Cookbook as:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/457407

The sample application handles the combination Ctrl+Y Alt+3 Shift+B,
and should handle just about anything else you want to throw at it
(I use some of the underlying menu handling code in PyPE
(http://pype.sf.net), which this borrows from).

I tried here and looks nice, thanks for sharing it. But it seems that
it will only work as long as you have focus on the control you bound
the EVT_FOCUS event. Also, if you bind EVT_FOCUS to all children,
you'll have to use only widgets that may be bound to a EVT_KEY_DOWN,
or make sure that there's always a widget with focus that may receive
key events. It's not that hard to implement that, though.

-- tacao

No bits were harmed during the making of this e-mail.

9

Tuesday, November 22, 2005, 3:52:42 AM, Josiah Carlson wrote:

> Because people have been having issues with this, I went ahead and
> hacked up a sample which allows for unlimited level keyboard
> shortcuts with or without menus.

> It is available in the Python Cookbook as:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/457407

> The sample application handles the combination Ctrl+Y Alt+3 Shift+B,
> and should handle just about anything else you want to throw at it
> (I use some of the underlying menu handling code in PyPE
> (http://pype.sf.net), which this borrows from).

I tried here and looks nice, thanks for sharing it.

Thanks.

But it seems that
it will only work as long as you have focus on the control you bound
the EVT_FOCUS event. Also, if you bind EVT_FOCUS to all children,
you'll have to use only widgets that may be bound to a EVT_KEY_DOWN,
or make sure that there's always a widget with focus that may receive
key events. It's not that hard to implement that, though.

Well, it's one of those things...there is only so much you can do with a
hierarchical event subsystem, but it's really the only event subsystem
that makes sense in most GUI toolkits.

- Josiah

···

"E. A. Tacao" <tacao@mailshack.com> wrote: