Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consistent key-events #619

Merged
merged 4 commits into from
May 8, 2019
Merged

consistent key-events #619

merged 4 commits into from
May 8, 2019

Conversation

umlaeute
Copy link
Contributor

@umlaeute umlaeute commented May 5, 2019

on linux, the <KeyRelease> event will not fill the %A value, leading to all kinds of inconsistent behaviour.

sendkey .pdwindow.text 1 h h 0     # keypress 'h'
sendkey .pdwindow.text 0 h {} 0    # keyrelease 'h'
sendkey .pdwindow.text 1 plus + 0  # keypress '+' (%K="plus", %A="+")
sendkey .pdwindow.text 0 plus {} 0 # keyrelease '+'

This PR tries to fix the problem, by using a cached value of %A value (e.g. received through <KeyPress>) if necessary.

The solution uses dict, which requires Tcl>8.5; older tcl-versions will fall back to the original behaviour (tested with Pd-0.49-0/OSX/PowerPC that uses Tcl-8.4 ).

@umlaeute umlaeute changed the base branch from master to update/0.50 May 5, 2019 19:23
@umlaeute
Copy link
Contributor Author

umlaeute commented May 7, 2019

i've tested this on linux and OSX; probably some Windows user (@Spacechild1 , @Lucarda ?) could test as well.

my testing scheme is like this:

[keyname ]      [key]        [keyup]
|        |      |            |
[pack f s]      [print key]  [print keyup]
|
[print keyname]
  • open the test-patch
  • clear the console (via the menu)
  • press all buttons on the keyboard (from the upper-left corner to the lower-right corner)
  • repeat with ⇧Shift resp. Alt Gr (usually only for a subset, e.g. the numeric row)
  • save the Pd-console (via the menu)

doing this for both the updates/0.50 and the bugfix/keys and compare the results.

@umlaeute umlaeute requested a review from danomatika May 7, 2019 11:48
@Lucarda
Copy link
Contributor

Lucarda commented May 7, 2019

@umlaeute

I did the tests only replacing the tcl folder of both PRs (updates/0.50 & bugfix/keys) on my 0.49. Is that OK or i missed something?

both tests gave the same results:

pdwindow-key-all.txt

@umlaeute
Copy link
Contributor Author

umlaeute commented May 7, 2019

that's perfect, thanks. (it shows that the patch didn't introduce a regression; since the Windows-version was fine in the first place, that's good enough)

@Lucarda
Copy link
Contributor

Lucarda commented May 7, 2019

key: 59
keyname: 1 \\;
keyup: 59
keyname: 0 \\;

Is for my Spanish keyboard for the letter ñ but the OS is set to use an English keyboard. ñ is an extra fisical key.

@umlaeute
Copy link
Contributor Author

umlaeute commented May 7, 2019

i'm not sure i understand.

  • afaict the ñ key (on Spanish keyboard) is right of L
    • this is the location of ; on a US layout
  • you have switched your keyboard layout (on software) to US
  • if you press the ñ key in Pd, you get ; (which I think is expected)
  • which character do you get when you press the ñ in some other application (Word, notepad++,...)?

@Lucarda
Copy link
Contributor

Lucarda commented May 7, 2019

Oh yes I get ;.
keyname: 1 \\;
the \\ had fool me.
:)

@danomatika
Copy link
Contributor

Looks good to me. Yet another one of those cross-platform inconsistencies, sigh.

@umlaeute umlaeute merged commit 3c8a3dd into update/0.50 May 8, 2019
@umlaeute umlaeute deleted the bugfix/keys branch May 8, 2019 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants