problems with Tk key release

[danom...@gmail.com]

Howdy all,

We've finally transitioned an open source project (Pure Data http://puredata.info) from TK 8.4 to TK 8.5+ on macOS and have run into a couple problems that may be related to the Cocoa key event handling.

---
1. KeyRelease binding returns immediately

The PureData Tk GUI binds to all key press events for certain window types and forwards them to it's companion server for processing. Originally, when pressing a key a KeyPress is generated and then a KeyRelease after the key is released (as expected!). We're now noticing with the newer Tk versions, the KeyRelease happens immediately *after* the KeyPress.

Here's a minimal test:

~~~
package require Tk

bind . <KeyPress> {puts "press %K"}
bind . <KeyRelease> {puts "release %K"}
~~~

I created a ticket but have not heard anything: https://core.tcl.tk/tk/tktview/1ba71a86bb6ab29180418ba4a25b0074e3c9de7a

More info can be found here: https://github.com/pure-data/pure-data/issues/213

---
2. Shift key bindings on French keyboard mappings

The PureData Tk GUI uses MOD+SHIFT+key bindings which are also set as menu accelerators. This works fine with the English keyboard mapping. We're now running into issues with other keyboard locales, namely French so far, where the bindings with Shift result in the menu accelerator firing so it may be an issue with the menu event filtering.

For example, the "Bang" shortcut is bound as:

bind all <$::modifier-Shift-Key-B> {menu_send %W bng}
bind all <$::modifier-Shift-Key-b> {menu_send %W bng}

and the menu item:

$mymenu add command -label [_ "Bang"] -accelerator "$accelerator+Shift+B" \
-command {menu_send $::focused_window bng}

With the English keyboard mapping, the $::modifier-Shift-Key-b fires and the menu item's command is ignored (expected behavior).

With the French keyboard mapping, the $::modifier-Shift-Key-B fires AND the menu item command fires. It seems as though the capital B doesn't get matched to the menu accelerator binding.

The German keyboard mapping behaves the same as the English one.

-----
Dan Wilcox
danomatika.com
robotcowboy.com

[danom...@gmail.com]

(Whoops, forgot second half of subject line.)

[Christian Gollwitzer]

Am 27.03.18 um 03:14 schrieb danom...@gmail.com:

> The PureData Tk GUI binds to all key press events for certain window types and forwards them to it's companion server for processing. Originally, when pressing a key a KeyPress is generated and then a KeyRelease after the key is released (as expected!). We're now noticing with the newer Tk versions, the KeyRelease happens immediately *after* the KeyPress.
>
> Here's a minimal test:
>
> ~~~
> package require Tk
>
> bind . <KeyPress> {puts "press %K"}
> bind . <KeyRelease> {puts "release %K"}
> ~~~
>
> I created a ticket but have not heard anything: https://core.tcl.tk/tk/tktview/1ba71a86bb6ab29180418ba4a25b0074e3c9de7a
>
> More info can be found here: https://github.com/pure-data/pure-data/issues/213
>

Can this be related to autorepeat? I've got some faint memory that there
is a new "input manager" in newer OSX which messes things up and
previously led to crashes even. On a German keyboard, the key "a", e.g.,
autorepeats, while key "f" and "g" don't autorepeat - easily tested in a
tkcon. On the command line of the terminal window, all keys autorepeat.

The mystery becomes clearer in a text input Window, try holding a key in
e.g. the Safari address bar - then holding "e" pops up a small Window
showing accented versions of "e" èêë etc, similar to input on phones.
That explains the different behaviour: The Tk Window has a bug, it
wothholds the events, but doesn't show the popup either.
I think to solve the problem, we would need to find out what trick the
Termminal app uses to revert the behaviour.

Christian

[danom...@gmail.com]

On Tuesday, March 27, 2018 at 8:08:48 AM UTC+2, Christian Gollwitzer wrote:
>
> Can this be related to autorepeat? I've got some faint memory that there
> is a new "input manager" in newer OSX which messes things up and
> previously led to crashes even. On a German keyboard, the key "a", e.g.,
> autorepeats, while key "f" and "g" don't autorepeat - easily tested in a
> tkcon. On the command line of the terminal window, all keys autorepeat.

The KeyRelease returning immediately happens whether system key repeat is on or off.

Also, for the English keyboard, I am indeed seeing "a" autorepeat with system key repeat off..

[danom...@gmail.com]

On Tuesday, March 27, 2018 at 8:08:48 AM UTC+2, Christian Gollwitzer wrote:
>

> On the command line of the terminal window, all keys autorepeat.

> ...

> I think to solve the problem, we would need to find out what trick the
> Termminal app uses to revert the behaviour.

This seems to be intended behavior judging from https://support.apple.com/en-us/HT201586:

~~~
Some keys repeat when you hold them down, depending on where you type them. Hold down the Space bar or symbol keys (like hyphen or equals) to make these characters repeat in most apps. In apps where accented characters aren't used—like Calculator, Grapher, or Terminal—letter and number keys also repeat when you hold them down.
~~~

From that text, maybe we can assume Terminal ignores/disables the accented character popup. NSEvent has the isARepeat method though... I think I will make a test Cocoa app to investigate.

[danom...@gmail.com]

(Note: I've gone ahead and moved the second issue to it's own post/thread.)