app/internal/window: allow punctuation as keycode events v1 PROPOSED

Larry Clapp: 1
 app/internal/window: allow punctuation as keycode events

 1 files changed, 1 insertions(+), 1 deletions(-)

> On Sun Nov 17, 2019 at 9:01 PM Larry Clapp wrote:
> > Allows things like Ctrl-{.
> > 
> > All punctuation is returned as-is, e.g. "!" is "!", not (on my
> > keyboard) Shift-1, and "{" is "{", not (on my keyboard) Shift-[.
> 
> The intention of key.Event.Name is that it contains the unmodified
> key name, usually what is printed on the physical key. So in your
> case, Shift+1 should result in Name = "1", just like pressing 1
> without shift does.
That makes sense for letters, but I don't understand the usefulness
for punctuation, especially given that the output of "shift-1" on one
keyboard may be different from the output of "shift-1" on another.
(Although "shift-2" or "shift-4" seem like better examples of things
that actually vary.)

On QWERTY, ";" is just ";". �On QWERTZ, ";" is "shift-,". �Several
other punctuation symbols are shifted on one keymap and not on
another. �Some of what I consider "regular punctuation" appear to be
only reachable via AltGr on some keymaps, though I'm not sure about
that.  (This is all based on a few minutes browsing Wikipedia about
keymaps, so take it with a grain of salt.)

My point is, what will Gio users (and *their* users) want to do? �I,
for one, would rather write code for "@" instead of "shift-2", and I'd
especially like to write code for "<" instead of "shift-,", because on
the German QWERTZ layout, "<" is an unshifted key, and "shift-," is
";"! �I think what you're suggesting would force Gio users to either
re-implement keymaps (probably badly), or ignore them.

I could of course be missing something.  :)
 

[PATCH] app/internal/window: allow punctuation as keycode events Export this patch

Allows things like Ctrl-{.

All punctuation is returned as-is, e.g. "!" is "!", not (on my keyboard)
Shift-1, and "{" is "{", not (on my keyboard) Shift-[.

Elias Naur

8 months ago

The intention of key.Event.Name is that it contains the unmodified key
name, usually what is printed on the physical key. So in your case,
Shift+1 should result in Name = "1", just like pressing 1 without shift
does.

The problem seems to be that the macOS backend uses

	      NSString *keys = [event charactersIgnoringModifiers];

to get "unmodified" keys for the NSEvent. However,
charactersIgnoringModifiers does not ignore the Shift key, according to
its documentation:
> The characters generated by a key event as if no modifier key (except
for Shift) applies.

So charactersIgnoringModifiers is too high-level.

NSEvent also gives us "keyCode" that truly ignores all modifiers.
Unfortunately keyCode is too low-level, because keyCode does not take
the user's keyboard layout into account.

It seems the Goldilocks solution is to drop charactersIgnoringModifiers
and use keyCode with something like UCKeyTranslate to achieve a true
charactersIgnoringModifiers.

Do you want to work on that? If not, please file a TODO so we won't
forget.

Signed-off-by: Larry Clapp <larry@theclapp.org>
---
 app/internal/window/os_macos.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/internal/window/os_macos.go b/app/internal/window/os_macos.go
index 018bf64..c803c1f 100644
--- a/app/internal/window/os_macos.go
+++ b/app/internal/window/os_macos.go
@@ -301,7 +301,7 @@ func Main() {
 }
 
 func convertKey(k rune) (string, bool) {
-	if '0' <= k && k <= '9' || 'A' <= k && k <= 'Z' {
+	if '!' <= k && k <= '`' || '{' <= k && k <= '~' {
 		return string(k), true
 	}
 	if 'a' <= k && k <= 'z' {
-- 
2.23.0