[haiku-development] Re: Keymaps
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 14 May 2012 18:00:19 +0200
On Sun, May 13, 2012 at 11:02:38PM +0200, Siarzhuk Zharski wrote:
> Am 10.05.2012 22:23, schrieb pulkomandy:
> >System-wide shortcuts are (or should be) configurable, while
> >shortcuts in applications aren't. Localization of shortcuts also
> >makes this pretty messy, for example undo is Alt+Z on Azerty and
> >on Qwerty keyboards, so the key to press moves around, while on a
> >Cyrillic Keymap I expect it to be on the key labelled Z on Qwerty
> >(am I right ?).
>
> With cyrillic keymap no letter-based shortcuts are working at all. :-D
I know that. What I'm wondering is how they are usually mapped on others
OS. The decision of mapping shortucts to letters in the Be API matches
what is done elsewhere on latin keyboards. Z is always undo, even if it
moves around on the keyboard.
> BTW, Keymap Switcher has special "remapping" feature to change the
> character on the fly to corresponding latin one in case Cmd-modifier
> is active.
>
> >This means application shortcuts should be keymap dependant in a
> >non-straightforward way.
>
> This means that Haiku's implementation of shortcuts is far from perfection.
It is not only an implementation problem. We use shortcuts that matches
what is done elsewhere, and these are built out of history accidents.
Some of the shortcuts are put together because it makes sense (X/Cut
C/Copy V/Paste are on keys next to each other), others are mapped to
letters (Z/Undo Y/Redo are on consecutive letters), some are mapped to
whatever key was still free, and very often a mix of these 3 things.
So, the shortcuts we are all used to don't make a lot of sense. But I'm
not sure it's worth rethinking it (yet). Users will sure feel lost if we
start moving them around, and the result might not be better.
> I think that user can decide better which shortcut is more suitable
> for him personally. And we will be not responsible for his decision
> in case of shortcuts conflict. ;-)
Then, we need to make all the shortcuts configurable system-wide
somehow. But this is an R2 thing, as it willbreak the existing system
and API.
> BTW, using CapsLock/ScrollLock for KeymapSwitcher has clashed with
> default handling of this buttons in the input_server. They are
> available in the list but behaviour is not predictable. Yes, the
> CapsLock is very popular as keymaps switcher, but we have to hack
> input_server for this and let the CAPITALIZE FANS to switch this
> off.
The problem is in input_server, and we can fix that.
--
Adrien.
Other related posts:
