Forum > Editor

Keyboard AltGr key

<< < (4/5) > >>


--- Quote from: MaxCuriosus on February 07, 2022, 03:37:48 pm ---I'm not sure what to conclude. Which one of the following apply:

1) AltGr not planned to be implemented in Lazarus editor
2) The implementation has been overlooked
3) There is an incompatibility with Linux distribution
4) There is a bug
5) or else?

Note that with the same Lazarus version and keyboard, AltGr works fine with Debian 10.7!

--- End quote ---

Ok to clarify: AltGr should work. If it is not working, then this is a bug.
Unless documented as unsupported for specific Linux versions: Maybe specific kernel version, or Gtk version, or IM module....
I am not aware of such docs at current.

"An incompatibility" can be a bug too.

If it is a bug, it has however to be established if that bug is part of the LCL/Lazarus Code. Or if it is part of some other software/driver on that OS.
I.e., just because other apps like GEdit work with a specific setup does not mean that the setup does not have a bug. (It's complicated)

If it is a bug in the LCL/Lazarus, then the question is, if it can be reproduced by someone who is also able to write a fix. (And to verify that the fix does not break other conditions. E.g. if gtk doc says "must handle "foo=x" and the current implementation has code like "if foo=x then", then the patch must not remove this without explaining how it is handled in future....)

Apropos "IM"

Some IM modules have caused other key input issues in the past. Maybe changing the IM setting can work-around (and narrow the issue).

Also, one of my above posts linked-to/quoted  un-tested IM related Lazarus code (IFDEF). That code is not currently in use, but can be activated for testing. So who knows....,46731.msg333712.html#msg333712

On the "is it a bug" question. If there is no already existing report, then it can certainly be reported to our issue tracker.
If it turns out, that it is something else, or somewhere else...., It can still be closed then.

However, looking at the related issues, it may still make sense to work out as much extra info as possible. Even though, I do not know if this will in any way affect the outcome.

For completeness sake, maybe I should point out: I am not the Gtk-WS maintainer. I will (99.99% likely) not work on the actual fix of the issue.
Hence, I can not tell how helpful further info really will be.
The above "pointers" towards possible causes or workarounds are purely based, on me following (as observer) prior discussions on related issues.

Test #1

Tools > Options > Key Mappings > Find key combination
> Load a scheme: Lazarus default or Classic
> Grab key
      AltGr yields Alt OEM_0xE3, it doesn't expect a second key
    Other keys or key combinations seem to match exactly the standard en-US keyboard.

Test #2

This Debian 11 system is setup with 3 different input sources(keyboards) in this order:
English (US)
French (Switzerland)

With the Gnome settings utility I changed the list order to put the desired French keyboard on top and that eliminates the anomaly, even without restarting Lazarus! The same applies to Debian 10.

Is it still a bug, and if so where? Lazarus, Debian, Gnome or else?


--- Quote from: MaxCuriosus on February 08, 2022, 04:17:21 pm ---> Grab key
      AltGr yields Alt OEM_0xE3, it doesn't expect a second key
    Other keys or key combinations seem to match exactly the standard en-US keyboard.

--- End quote ---
ok, that is strange...

This looks to me (but I may be wrong), as if on your setup "AltGr" produces an actual key.
Probably a "dead key" (but that is really a wild guess). "dead keys" are e.g. on some keyboards accents, which you press (and release, you do not hold them) and then the next key will produce an accented char...

Obviously from a pure technical point of view, producing such a dead key would work. The next e.g. "q" would give an "@" (ignoring that you still hold the AltGr.

If indeed that is the case, well I find it surprising. AltGr is usually meant to act as modifier key (like shift/ctrl) that act as long as they are pressed.
Also, if they produce a dead key, what happens if you press "q" several times (and keep AltGr down all the time). That wouldn't work with dead keys. So if that works on your setup, then I have no idea what is going on.

Anyway as I said: Wild guesses. No idea.

Though if it is a "dead key", then it may be related to the "dead key" bug that I linked earlier (or any of the other bugs in that category)....

--- Quote ---Is it still a bug, and if so where? Lazarus, Debian, Gnome or else?

--- End quote ---
Sorry, no idea.

If in doubt, report it as a bug. Worst case it gets closed.

Link to the "dead key" issue - in case...

Despite the above leaving me clueless (i.e. not matching any prior case that I have seen), I do have a gut feeling it is IM related ("IM" => "Input Manager", search the forum or bug tracker / there are several IM that can be installed in Linux).

And, if it is IM, look at the defines I pointed out. Some one did contribute some code there, that he said adds some IM handling. This code has not yet been fully reviewed. So it's not active by default. But if compiled with the defines given, then it will be active.
Could be a lucky strike, and help with the issue. Or not. I can't test it, since none of my Linux systems has any of those issues.


Different values in german surrounding:

AltGr returns decimal 235 = $EB

A comment in LCLtype says:

$E9-$F5 OEM specific

(line 608)

Tested with TForm1.Keydown and with the keygrabber from the IDE tools.



[0] Message Index

[#] Next page

[*] Previous page

Go to full version