Git commit 1ae43956e2bfb933d63fc774ca8e4ed22e4108dd killed my AltGR key

[gnuwimp]

"Quick fix for Window Ctrl charcter handling."
int condition = (Fl::e_state & (FL_ALT | FL_META | FL_CTRL)) && !(ascii & 128) ;
It is the additional FL_CTRL value that breaks it.
I'm using a Swedish layout and without AltGR I can't enter any of
these characters "@${[]}".

[Greg Ercolano]

    I've added a github comment to the commit, which is perhaps the right way to report a problem with a particular commit; see:
    https://github.com/fltk/fltk/commit/1ae43956e2bfb933d63fc774ca8e4ed22e4108dd

[imacarthur]

As an aid, can you (OP) post the (hex) values that you are seeing (in "Fl::e_state" and "ascii", I guess) for various key combinations that involve your AltGr key, please?

FWIW, on the keyboard I using right now, tested under Win-10, pressing AltGr does set both FL_ALT and FL_CTRL.

But I don't have a Swedish keyboard (indeed, I went raking about in the junk at the back of the garage and found UK, US, DE, FR boards of various antiquities, and not necessarily still working, but no Scandinavian one of any sort...)

(As an aside, I haven't tried it under X11 yet because I don't have an X11 system readily to hand, and anyway X11 is weird about delivering modifier keys...)

 

[melcher....@googlemail.com]

Thanks for the bug report. I am reversing the commit as I write this. I was not aware that "AltGr" on Windows is seen as FL_CTRL. So much for innocent changes.

[Albrecht Schlosser]

@Matthias: I'm not sure if this report is "correct", there may be
another cause why the OP doesn't see the correct input text. First I
thought that my own keyboard patch would perhaps "fix" this issue as
well, but then I couldn't reproduce the OP's issue with my keyboard set
to Swedish. I see all AltGr+X characters entered as expected. We need
more info...

[imacarthur]

On Monday 2 September 2024 at 11:20:47 UTC+1 Albrecht-S wrote:

On 9/2/24 11:54 Matt wrote:

> Thanks for the bug report. I am reversing the commit as I write this.
> I was not aware that "AltGr" on Windows is seen as FL_CTRL. So much
> for innocent changes.

@Matthias: I'm not sure if this report is "correct", there may be
another cause why the OP doesn't see the correct input text. First I
thought that my own keyboard patch would perhaps "fix" this issue as
well, but then I couldn't reproduce the OP's issue with my keyboard set
to Swedish. I see all AltGr+X characters entered as expected. We need
more info...

All,

I'm still interested to hear what the OP actually sees in the pertinent values when used with their kbd.

For the record, one of my kbd's is a very minimal UK-style layout. It has no AltGr key (indeed no right-hand modifiers at all) but under Win-10 I can generate "the same" effect as AltGr by holding down L_CTRL + L_ALT simultaneously (plus key to be modified of course.)

So I think that Windows expects (or at least tolerates...) AltGr to be equivalent to ALT + CTRL. Maybe.

I have no idea what that kbd does on X11 - it's used for a very specific setup!

[melcher....@googlemail.com]

I just wanted to revert my changes ASAP because they currently did not really fix anything, but were required for some of Albrecht's private code. In any case, we need to be super careful about any change in the keyboard routines, even if they seem benign. I assume we need to add some AltGr flag and more foreign keyboard handling at some point. 

[Albrecht Schlosser]

On 9/2/24 14:38 'melcher....@googlemail.com' via fltk.coredev wrote:

I just wanted to revert my changes ASAP because they currently did not really fix anything, but were required for some of Albrecht's private code.

To clarify: that was not "my private" code but code I am developing to fix Win32 keyboard handling in general. I did not yet push this code though. The main goal is to make ctrl/+/- work on all international keyboards but it turned out to be a lot more complicated than anticipated. Well, it's Windows, you know... ;-)

In any case, we need to be super careful about any change in the keyboard routines, even if they seem benign. I assume we need to add some AltGr flag and more foreign keyboard handling at some point.

I'm investigating further. For those interested: yes, it seems that Windows generates two distinct keyboard events for AltGr which are shown below, using test/handle_keys.cxx. Given that Windows "hides" the AltGr key (sending CTRL + ALT) but still "interprets" the correct text associated with AltGr I'm wondering if it is possible to detect AltGr at all in FLTK's event handling. Details:

From GitHub 'master' (output is the same as from my WIP):

[nnn] Event           Key     Name,  Flags: C A S M N L  Text  Unicode   UTF-8/hex
[180] FL_KEYDOWN      0xffe3  FL_Control_L  C . . . . .  ''
[181] FL_KEYDOWN      0xffea  FL_Alt_R      C A . . . .  ''
[182] FL_KEYUP        0xffe3  FL_Control_L  . A . . . .  ''
[183] FL_KEYUP        0xffea  FL_Alt_R      . . . . . .  ''

I'm using this Swedish keyboard layout for reference:




Here is some more output from test/handle_keys.cxx, both with the old 'master' branch (before the revert) and with my "private" WIP (work in progress) - with some added comments, see '<<< COMMENT':

*** Windows Swedish Keyboard (SV), branch master bevore revert (aa6ce6b9f)

[  1] FL_KEYDOWN      0x0079  'y'           . . . . . .  'y'   U+0079    79
[  2] FL_KEYDOWN      0xffe3  FL_Control_L  C . . . . .  ''
[  3] FL_KEYDOWN      0xffea  FL_Alt_R      C A . . . .  ''
[  4] FL_KEYDOWN      0x0071  'q'           C A . . . .  ''
[  5] FL_KEYDOWN      0x0065  'e'           C . . . . .  '€'   U+20ac    e2 82 ac <<< correct

Keyboard (SV) 'number' keys (top row, not num. keypad)
... with AltGr:

[  6] FL_KEYDOWN      0x0031  '1'           C A . . . .  ''                         <<< ? (see below and [1])
[  7] FL_KEYDOWN      0x0032  '2'           C . . . . .  '@'   U+0040    40
[  8] FL_KEYDOWN      0x0033  '3'           C . . . . .  '£'   U+00a3    c2 a3
[  9] FL_KEYDOWN      0x0034  '4'           C . . . . .  '$'   U+0024    24
[ 10] FL_KEYDOWN      0x0035  '5'           C . . . . .  '€'   U+20ac    e2 82 ac
[ 11] FL_KEYDOWN      0x0036  '6'           C A . . . .  ''                         <<< ? (see below and [1])
[ 12] FL_KEYDOWN      0x0037  '7'           C . . . . .  '{'   U+007b    7b
[ 13] FL_KEYDOWN      0x0038  '8'           C . . . . .  '['   U+005b    5b
[ 14] FL_KEYDOWN      0x0039  '9'           C . . . . .  ']'   U+005d    5d
[ 15] FL_KEYDOWN      0x0030  '0'           C . . . . .  '}'   U+007d    7d
[ 16] FL_KEYDOWN      0x003d  '='           C . . . . .  '\'   U+005c    5c   <<< event_key should be '+' (see below)


*** Windows Keyboard SV, WIP

[nnn] Event           Key     Name,  Flags: C A S M N L  Text  Unicode   UTF-8/hex
[  1] FL_KEYDOWN      0x0079  'y'           . . . . . .  'y'   U+0079    79
[  2] FL_KEYDOWN      0xffe3  FL_Control_L  C . . . . .  ''
[  3] FL_KEYDOWN      0xffea  FL_Alt_R      C A . . . .  ''
[  4] FL_KEYDOWN      0x0071  'q'           C A . . . .  'q'   U+0071    71
[  5] FL_KEYDOWN      0x0065  'e'           C . . . . .  '€'   U+20ac    e2 82 ac

Keyboard (SV) 'number' keys (top row, not num. keypad)
... with AltGr:

[  7] FL_KEYDOWN      0xffe3  FL_Control_L  C . . . . .  ''
[  8] FL_KEYDOWN      0xffea  FL_Alt_R      C A . . . .  ''
[  9] FL_KEYDOWN      0x0031  '1'           C A . . . .  '1'   U+0031    31         <<< ? (see above and [1])
[ 10] FL_KEYDOWN      0x0032  '2'           C . . . . .  '@'   U+0040    40
[ 11] FL_KEYDOWN      0x0033  '3'           C . . . . .  '£'   U+00a3    c2 a3
[ 12] FL_KEYDOWN      0x0034  '4'           C . . . . .  '$'   U+0024    24
[ 13] FL_KEYDOWN      0x0035  '5'           C . . . . .  '€'   U+20ac    e2 82 ac
[ 14] FL_KEYDOWN      0x0036  '6'           C A . . . .  '6'   U+0036    36         <<< ? (see above and [1])
[ 15] FL_KEYDOWN      0x0037  '7'           C . . . . .  '{'   U+007b    7b
[ 16] FL_KEYDOWN      0x0038  '8'           C . . . . .  '['   U+005b    5b
[ 17] FL_KEYDOWN      0x0039  '9'           C . . . . .  ']'   U+005d    5d
[ 18] FL_KEYDOWN      0x0030  '0'           C . . . . .  '}'   U+007d    7d
[ 19] FL_KEYDOWN      0x002b  '+'           C . . . . .  '\'   U+005c    5c   <<< event_key is correct ('+')

Looking at the output above I'm also wondering why the 'Alt' flag is not set in Fl::event_state() whereas the 'Ctrl' flag *is* set in most key combinations - except for keys '1' and '6' which don't have an AltGr interpretation (see keyboard layout above and [1]).

FWIW, the output of test/handle_keys.cxx can be seen as a "first stage" of keyboard input handling, i.e. this program displays the raw values in Fl::event_key() and Fl::event_text(). All input widgets must interpret these variables in the "second stage" of input handling, including Fl::compose() which Matthias tried to fix in his meanwhile reverted commit.

Weird stuff ...

Notes:

[1] Keys '1' and '6' don't have an 'AltGr' meaning in the given Windows keyboard layout, but see [2], so what would be the correct Fl::event_text() ? Maybe no text, i.e. the empty string?

[2] The Swedish keyboard layout displayed under Linux (Gnome) differs in some keys, particularly the number keys '1' and '6' which do have an AltGr interpretation in this layout. This doesn't make the entire keyboard handling stuff easier. :-(

[gnuwimp]

On Mon, Sep 2, 2024 at 4:37 PM gnuwimp <gnu...@gmail.com> wrote:
>
> > As an aid, can you (OP) post the (hex) values that you are seeing (in "Fl::e_state" and "ascii", I guess) for various key combinations that involve your AltGr key, please?
> > FWIW, on the keyboard I using right now, tested under Win-10, pressing AltGr does set both FL_ALT and FL_CTRL.
> > But I don't have a Swedish keyboard (indeed, I went raking about in the junk at the back of the garage and found UK, US, DE, FR boards of various antiquities, and not necessarily still working, but no Scandinavian one of any sort...)
> >
>

> Single press on AltGR
> Fl::e_state=0x40000, ascii=0
> Fl::e_state=0xC0000, ascii=0
>
> AltGR + 8 => '['
> Fl::e_state=0x40000, ascii=0x0
> Fl::e_state=0xC0000, ascii=0x0
> Fl::e_state=0x40000, ascii=0x5B

Added additional values.

AltGR + 7 => ''{"
Fl::e_state=0x40000, ascii=0x0, FL_ALT=0x80000, FL_META=0x400000,
FL_CTRL=0x40000
Fl::e_state=0xC0000, ascii=0x0, FL_ALT=0x80000, FL_META=0x400000,
FL_CTRL=0x40000
Fl::e_state=0x40000, ascii=0x7B, FL_ALT=0x80000, FL_META=0x400000,
FL_CTRL=0x40000

[gnuwimp]

> As an aid, can you (OP) post the (hex) values that you are seeing (in "Fl::e_state" and "ascii", I guess) for various key combinations that involve your AltGr key, please?
> FWIW, on the keyboard I using right now, tested under Win-10, pressing AltGr does set both FL_ALT and FL_CTRL.
> But I don't have a Swedish keyboard (indeed, I went raking about in the junk at the back of the garage and found UK, US, DE, FR boards of various antiquities, and not necessarily still working, but no Scandinavian one of any sort...)
>

[gnuwimp]

When I try keyboard.exe and press AltGR + '8' I get these values:

Fl::event_key() => '8'

Fl::event_text() => '['

And Ctrl + right alt is pressed.

So event text is ok but never reaches the input widgets.

[Albrecht Schlosser]

On 9/2/24 16:56 gnuwimp wrote:

When I try keyboard.exe and press AltGR + '8' I get these values:

Fl::event_key() => '8'

Fl::event_text() => '['

And Ctrl + right alt is pressed.

So event text is ok but never reaches the input widgets.

Did you update (`git pull`) your Git checkout? Matthias reverted the false commit, hence you should be fine again.

If you *did* update, please try test/input.exe and test/editor.exe after rebuilding and let us know what you see with these test programs.

[gnuwimp]

No I waited until now. I thought you would try to see what was the problem.
Everything works now with the latest commit.
Thumbs up.

[Albrecht Schlosser]

Well, Git is very helpful (I'm sure you know this, but anyway): we can switch to a particular commit to test it. No reason to "wait".

Everything works now with the latest commit.

Great, thanks for your confirmation.

Thumbs up.

Welcome.