[haiku-development] Re: Shortcut handling of shortcuts with shifted keys
- From: Ryan Leavengood <leavengood@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 2 Aug 2012 15:05:23 -0400
On Thu, Aug 2, 2012 at 2:48 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
>
> I think it's even worse: there can be two sorts of shortcuts - one where the
> location on the keyboard is important (for example even basic things like
> cut, copy & paste), and one where the character is important (zoom). There
> might even be inbetween cases :-)
For now I don't want to worry about scan-code based shortcuts, but it
probably wouldn't be all that hard to do.
> It only gets funny if you want the shortcut to be shift-+ :-)
Well the AltGr example you gave is another one, I'll bet Cmd-{ won't
work as a shortcut for you on a German keymap. Also any shortcut using
the shifted versions of the number keys won't work. I guess up until
now, + was really the only shifted character commonly used in
shortcuts.
> Anyway, I think the correct solution for a start (neglecting the exact
> positioning which would require an API change) would be to let the shortcut
> mechanism check the character first, filter out the modifiers that are
> needed to create that character -- and then check if there is a shortcut for
> it.
The problem right now is the keymap does not offset the character if
Cmd is down. So it is impossible (right now) to ever get a plus (+) to
the shortcut handling code with a US keymap. When you press
Cmd-Shift-= you get that, not Cmd-Shift-+. Otherwise your suggestion
would work.
The question is what implications would their be for masking Cmd in
the Offset method of BKeymap (so that shift still shifts things even
if Cmd is held)?
--
Regards,
Ryan
Other related posts:
