[haiku-development] Re: Bug #2499 Shortcuts based on default keymap

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
  • Date: Wed, 23 Oct 2013 02:49:26 -0400

On Wed, Oct 23, 2013 at 1:48 AM, Adrien Destugues <pulkomandy@xxxxxxxxx> wrote:
> On 2013-10-23 at 03:10:56 [+0200], John Scipione <jscipione@xxxxxxxxx>
> wrote:
>> We detect if you have a non-latin keymap, and if so, map these
>> shortcuts to letters that appear in the same positions on the default
>> US-International keymap rather than mapping them to the letters in the
>> current keymap.
>
> Why do that ? Isn't it enough to search for the requested symbol (for each
> shortcut) and act only if it's missing ?
>
> I'd use an algorithm like this:
>  - Window requests a shortcut for cmd+W
>  - Look for cmd+W in the current keymap
>  - If found, assign the shortcut there
>  - If not found, look in US international keymap
>  - Assign the shortcut at that key position

Well, you might have a mix of latin and non-latin keys on your keymap,
for example
Belarusian has e, a, and c, and the rest are non-latin. It seems like
a good idea to use the defaults for all shortcuts including select all
and copy even though you happen to have those letters available
because you don't have the rest.

Any Belarusian users please chime in if you see this and let us know
what you expect.

>> There is an additional problem of the mapping changing when you switch
>> keymaps as well, that would need to be handled, actually, it's already
>> a problem.
>>
>> My thought process here is that we add a B_KEYMAP_CHANGED message
>> constant similar to B_LOCALE_CHANGED that gets fired when the keymap
>> changes. We then update BWindow::MessageReceived() accept this
>> constant and when it is received we remove and add the shortcuts as
>> long as they aren't already taken, which we can check with
>> HasShortcut().
>
> This is more tricky than it looks: when you switch AZERTY/QWERTY for
> example, cmd+Z and cmd+W will have to be swapped. With your proposal this
> won't happen, because they each conflict with the other.

It would only be necessary to remap the shortcuts if you are switching
to or from a non-latin map. If you're switching between 2 latin
keymaps, for instance Spanish and French there would be no need to
remap the shortcuts, but, if you're switching between Belarusian and
Russian, or Belarusian and US then you must remap.

Still, there are most likely some complications here...

> I think this problem needs more thinking and work than just a few tweaks to
> the code. How do other systems/UI toolkits handle it, for example ?
> (someone non-latin keymap user around ? can you tell us what happens in
> Linux,Windows,OS X, ... ?) We may need to introduce a new shortcuts API
> alongside the old one that allows this to work. Without making it too
> painful to handle for app developers.

FWIW I checked how non-latin keymaps are handled in Mac OS X and
Windows, and they both implement this feature basically how I've
described, with the caveat that the shortcut modifier that appears in
the menu is printed with the latin equivalent character, e.g. Cmd+W,
rather than Cmd+ц.

FWIW I came up with my proposed solution before looking at how those
OS's work, great minds think alike it seems. :)

I'd prefer to avoid introducing a brand new shortcut API if possible,
it's not the kind of thing that would be likely to be completed in the
R1 timeframe, and I'd hope for a solution to #2499 before then.

Other related posts: