~eliasnaur/gio-patches

3 2

Re: [PATCH] app/internal/window: allow punctuation as keycode events

Details
Message ID
<20191118193126.GA36773@larrymbp14.local>
DKIM signature
missing
Download raw message
On Mon, Nov 18, 2019 at 04:48:32PM +0100, Elias Naur wrote:
> > I could of course be missing something.  :)
> 
> Maybe :) What is your use case?

I myself don't have one at the moment, it (modifier+punctuation) just
seemed like an odd thing to deliberately exclude.

> Just so we're on the same page: [...]
> 
> Event is also for shortcuts (such as Ctrl-C and Ctrl-V), where you
> also refer to the label on the physical buttons.

Understood.

> The issue is about special cases such as the hypothetical shortcut
> "Ctrl-Shift-1". Do you want to present that to the user as
> `Ctrl-Shift-1` or as `Ctrl-Shift-!`? macOS seems to prefer the
> latter, and checking GIMP on Linux, it also lists shortcuts such as
> `Ctrl-;` which on my Danish keyboard layout is accessed by pressing
> "Ctrl-Shift-,".

I'm fine with either ctrl-shift-1 or ctrl-shift-!.

> For extra confusion, you can't have a shortcut with "@" on my
> keyboard because that's entered with "Option-'", and macOS'
> charactersIgnoringModifiers ignores Option.

I'm not sure I follow.  With a small change to
app/internal/window/os_macos.go I got my app to print:

2019/11/18 14:01:39.152235 convertKey: Unknown rune: 64 @
2019/11/18 14:01:39.172308 key event: key.Event {@ ModShift|ModAlt}
2019/11/18 14:01:39.172328 unknown event: key.EditEvent {€}

The diff:

@@ -353,7 +354,9 @@ func convertKey(k rune) (string, bool) {
        case 0x20:
                n = "Space"
        default:
-           return "", false
+         log.Printf("convertKey: Unknown rune: %v %v", k, string(k))
+         n = string(k)
+         // return "", false

My app code:

	for _, ke := range gtx.Events(&gd.eventKey) {
		switch ke := ke.(type) {
		case key.Event:
			log.Printf("key event: %T %v", ke, ke)
			/*
			other stuff
			*/
		default:
			log.Printf("unknown event: %T %v", ke, ke)


It seems to see the Opt/Alt key just fine if you let it.  But I have a
stock QWERTY keyboard so again maybe I'm missing something.

I also got it to print stuff like

2019/11/18 14:10:26.070618 convertKey: Unknown rune: 42 *
2019/11/18 14:10:26.092890 key event: key.Event {* ModShift|ModAlt}
2019/11/18 14:10:26.092915 unknown event: key.EditEvent {°}

Where ° is of course shift-opt-8 aka shift-opt-*.

and

2019/11/18 14:10:26.478120 convertKey: Unknown rune: 38 &
2019/11/18 14:10:26.493364 key event: key.Event {& ModShift|ModAlt}
2019/11/18 14:10:26.493394 unknown event: key.EditEvent {‡}

where ‡ is shift-opt-7 aka shift-opt-&.

So ... Are you saying something like "I (Larry) can't have a shortcut
using ‡ because that requires the opt key and it's seen as
shift-opt-&"?

> So it seems key.Event should have two names, the raw name for games
> and the modified name for shortcuts. key.Event.Name is supposed to
> be the raw name, and that's why I'm pushing back on your patch, but
> I'm not opposed to adding, say, Code for the unmodified name and
> leaving Name for the modified name.
> 
> WDYT?

I think that would meet my (currently hypothetical) needs.  I think
I'd need some more examples before I understood the need for the Code
field or difference between that and the Name field.

I guess, in my example above, it's the difference between & and ‡?
But which is which?  Is & Name or Code?

-- L

Re: [PATCH] app/internal/window: allow punctuation as keycode events

Details
Message ID
<BYJAXVWPIP5W.R9BZHCKJY0J2@toolbox>
In-Reply-To
<20191118193126.GA36773@larrymbp14.local> (view parent)
DKIM signature
pass
Download raw message
On Mon Nov 18, 2019 at 2:31 PM Larry Clapp wrote:
> On Mon, Nov 18, 2019 at 04:48:32PM +0100, Elias Naur wrote:
> > > I could of course be missing something.  :)
> > 
> > Maybe :) What is your use case?
> 
> I myself don't have one at the moment, it (modifier+punctuation) just
> seemed like an odd thing to deliberately exclude.
> 
> > Just so we're on the same page: [...]
> > 
> > Event is also for shortcuts (such as Ctrl-C and Ctrl-V), where you
> > also refer to the label on the physical buttons.
> 
> Understood.
> 
> > The issue is about special cases such as the hypothetical shortcut
> > "Ctrl-Shift-1". Do you want to present that to the user as
> > `Ctrl-Shift-1` or as `Ctrl-Shift-!`? macOS seems to prefer the
> > latter, and checking GIMP on Linux, it also lists shortcuts such as
> > `Ctrl-;` which on my Danish keyboard layout is accessed by pressing
> > "Ctrl-Shift-,".
> 
> I'm fine with either ctrl-shift-1 or ctrl-shift-!.
> 
> > For extra confusion, you can't have a shortcut with "@" on my
> > keyboard because that's entered with "Option-'", and macOS'
> > charactersIgnoringModifiers ignores Option.
> 
> So ... Are you saying something like "I (Larry) can't have a shortcut
> using ‡ because that requires the opt key and it's seen as
> shift-opt-&"?
> 

Exactly, at least if we want to be consistent with macOS'
charactersIgnoringModifiers. We could make ‡ possible, but then what about
opt-e, which gives "é"?

It was a minor point, I merely noted how arbitrary charactersIgnoringModifiers
seems to be. Perhaps applying Shift but ignoring other modifiers is just the
pragmatic choice given the variety of shortcuts and keyboard layouts.

> > So it seems key.Event should have two names, the raw name for games
> > and the modified name for shortcuts. key.Event.Name is supposed to
> > be the raw name, and that's why I'm pushing back on your patch, but
> > I'm not opposed to adding, say, Code for the unmodified name and
> > leaving Name for the modified name.
> > 
> > WDYT?
> 
> I think that would meet my (currently hypothetical) needs.  I think
> I'd need some more examples before I understood the need for the Code
> field or difference between that and the Name field.
> 
> I guess, in my example above, it's the difference between & and ‡?
> But which is which?  Is & Name or Code?
> 

"key code" is usually the term for the most raw identifier for the key, so in
your example "Code" would be "7" and "Name" would be "&". "‡" appears only in
EditEvents.

NSEvent's keyCode is almost what we want for "Code", except that it disregards
the current keyboard layout.

NSEvent's charactersIgnoringModifiers is what we want for (the new meaning of)
"Name".

Of course, the other platforms will have to change to match the new meaning of
Name and to implement Code.

Re: [PATCH] app/internal/window: allow punctuation as keycode events

Details
Message ID
<20191119144308.GA41647@larrymbp14.local>
In-Reply-To
<BYJAXVWPIP5W.R9BZHCKJY0J2@toolbox> (view parent)
DKIM signature
missing
Download raw message
On Mon, Nov 18, 2019 at 09:23:54PM +0100, Elias Naur wrote:
> On Mon Nov 18, 2019 at 2:31 PM Larry Clapp wrote:
> > I guess, in my example above, it's the difference between & and ‡?
> > But which is which?  Is & Name or Code?
> 
> "key code" is usually the term for the most raw identifier for the
> key, so in your example "Code" would be "7" and "Name" would be "&".
> "‡" appears only in EditEvents.
> 
> NSEvent's keyCode is almost what we want for "Code", except that it
> disregards the current keyboard layout.
> 
> NSEvent's charactersIgnoringModifiers is what we want for (the new
> meaning of) "Name".
> 
> Of course, the other platforms will have to change to match the new
> meaning of Name and to implement Code.

And if (when?) theirs are different, that could be really exciting.
(</sarcasm>).

Anyway, Name & Code sounds good.  It should probably be marked
"experimental".  Though arguably *all* of Gio is that.  :)

-- Larry

Re: [PATCH] app/internal/window: allow punctuation as keycode events

Details
Message ID
<BYK68RFHO3IW.11WMP2F2037TX@testmac>
In-Reply-To
<20191119144308.GA41647@larrymbp14.local> (view parent)
DKIM signature
pass
Download raw message
On Tue Nov 19, 2019 at 9:43 AM Larry Clapp wrote:
> On Mon, Nov 18, 2019 at 09:23:54PM +0100, Elias Naur wrote:
> > On Mon Nov 18, 2019 at 2:31 PM Larry Clapp wrote:
> > > I guess, in my example above, it's the difference between & and ‡?
> > > But which is which?  Is & Name or Code?
> > 
> > "key code" is usually the term for the most raw identifier for the
> > key, so in your example "Code" would be "7" and "Name" would be "&".
> > "‡" appears only in EditEvents.
> > 
> > NSEvent's keyCode is almost what we want for "Code", except that it
> > disregards the current keyboard layout.
> > 
> > NSEvent's charactersIgnoringModifiers is what we want for (the new
> > meaning of) "Name".
> > 
> > Of course, the other platforms will have to change to match the new
> > meaning of Name and to implement Code.
> 
> And if (when?) theirs are different, that could be really exciting.
> (</sarcasm>).
> 

We'll tackle one at a time, as always :)

> Anyway, Name & Code sounds good.  It should probably be marked
> "experimental".  Though arguably *all* of Gio is that.  :)
> 

Indeed!