Re: [Pharo-dev] Cross platform key modifiers
On 23 May 2015 6:36 am, "Nicolai Hess" <nicolaihess@web.de> wrote:
Hi ben,
2015-05-22 17:28 GMT+02:00 Ben Coman <btc@openinworld.com>:
Not sure what past history we inherited, but I am questioning the
semantics of our key modifiers. My understanding is that the following is industry standard...
OSX Windows Linux option alt alt cmd ctrl ctrl
Yes, this is what I expected too. And I thought this is what KMCommandModifier is used for. With that, I would expect "Character arrowLeft command" maps to Ctrl+Left for windows/linux Meta+Left for Mac
(If Meta is the Command-Key on a Mac keyboard).
No. On a Mac the "command" key is "Cmd" -- hence why I think we should not call it "command" internally, to help maintain platform independent semantics.
with Copy being the simplest example of this... cmd-c ctrl-c ctrl-c
Supporting this view: * "option" and "alternative" are synonyms * "command" and "control" have similar meaning (e.g. in the army if you
command someone, you control them)
* Microsoft say so (https://support.microsoft.com/en-us/kb/970299) * Apple say so (https://support.apple.com/kb/PH18812?locale=en_US) and indeed marks its keyboards with "alt" and "option" on the same key ( http://www.apple.com/au/keyboard/)
So examining this with KMLog setDebug.Transcript open.
On OSX Pharo 50044 I get... option+arrowLeft --> [keystroke '<Opt-left>'] cmd+arrowLeft --> [keystroke '<Cmd-left>'] ctrl+arrowLeft --> OS changes screens
but I am told that Windows gives... alt+arrowLeft --> [keystroke '<Cmd-left>'] ctrl+arrowLeft --> [keystroke '<Ctrl-left>']
when I believe Windows should be... alt+arrowLeft --> [keystroke '<Opt-left>'] ctrl+arrowLeft --> [keystroke '<Cmd-left>']
Part of the issue I think is that our keystroke mapping should be more abstract.
When I was using Pharo on Windows, sometimes it felt like a second class citizen wrt key mappings, mapping ctrl-c to an apple-named <cmd-c>. Perhaps what we should see is:
OSX... option+arrowLeft --> [keystroke '<Meta-left>'] cmd+arrowLeft --> [keystroke '<Hotkey-left>']
Windows... alt+arrowLeft --> [keystroke '<Meta-left>'] ctrl+arrowLeft --> [keystroke '<Hotkey-left>']
Otherwise there will always be the tension on windows that ctrl-c should generate [<keystroke '<Ctrl-c>] and we end up with definitions repetitively formed like... PharoShortcuts>>acceptShortcut ^ $s ctrl win | $s ctrl unix | $s command mac
which opens the door for inconsistencies. We should only need to do something like... PharoShortcuts>>acceptShortcut ^ $s hotkey
Isn't OSXs Command-key like MS-Windows "Window" or Linux "Meta" -key?
No. I know they both have nice icons, but they are not the same. You don't use the windows key to copy text. Cheers -ben
and leave it to the platform default or user preference the define what
the hotkey actually is. A status line in the Keymap Browser could display which actual real keys map to <Hotkey> and <Meta>.
What are you thoughts? cheers -ben
2015-05-23 9:52 GMT+02:00 Ben Coman <btc@openinworld.com>:
(If Meta is the Command-Key on a Mac keyboard).
No. On a Mac the "command" key is "Cmd" -- hence why I think we should not call it "command" internally, to help maintain platform independent semantics.
Yes and I thought this was the reason to define one Command-Modifier (Ctrl on Windows, because you use Ctrl+C for copy, Command on Mac, because you use Cmd+C for copy on a Mac) and map. (and we are using "Command" instead of a platform independent name, because many squeak-keyshortcuts had its history from the old first implementation for a mac. And users are used to this semantics.
No. I know they both have nice icons, but they are not the same. You don't use the windows key to copy text. Cheers -ben
Yes, exactly, they are the same keys but used for different purposes on each platform. Windows uses the ctrl-key for copy/paste, the alt-key for the menu bar, the Windows/Meta key for Desktop and Shell shortcuts. Mac uses the Meta/Command key copy/paste. -> I think we can not really use a platform independent schema, if the platform reserved the keys for its own purpose.
participants (2)
-
Ben Coman -
Nicolai Hess