search

kryslt / KControls

Free components for Delphi and Lazarus, this is the main repository maintained by the original author.
BSD 3-Clause Clear License
58 stars 32 forks source link

Spurious characters on compose sequence input. #31

Closed munizao closed 3 years ago

munizao commented 3 years ago

I initially encountered this problem in tomboy-ng, but I then created a project in Lazarus with just a KMemo, so I can verify that it's not their fault. The rest of this is pasted from the issue I submitted there.

I am running Linux Mint 20 Ulyana.

When I type in characters using a compose sequence, extra spurious characters are inserted. For example, when I type: [compose] n ~ I get: ñ (That's a 000E character before the 'ñ', if that doesn't come through.) The extra character comes when I type the n, then the 'ñ' is input as normal when I type the '~'. When I type: [compose] x x I get: × (Those are two 0018 characters before the '×' if they don't come through. Or maybe 001B, what I see is a box with that in it, but there aren't enough pixels to tell an 8 from a B.) In this case, I get the first spurious character when I type the first x, and the second spurious character and the correct character together when I type the second x.

kryslt commented 3 years ago

I tried this and debugged on my Ubuntu down to gtk2 interface level. Lazarus still uses gtk2 interface by default, I am not sure what widgetset tomboy-ng uses. But with gtk2 I can confirm the problem. It seems the bug is not in KMemo but rather in Lazarus LCL itself. LCL sends those spurious characters (eg 0018) as if really pressed. But it should not. The bug is not present in standard TMemo or TEdit because they are standard system components. Maybe reporting this issue on Lazarus bugtracker will help? I think the problem is in function HandleGTKKeyUpDown in gtk2proc.inc.

EDIT: I've found this similar issue here. Furthermore, I can confirm that compose input does not work even in Lazarus source code editor. Instead of ñ it produces always n~, for example. This is because of slightly different keyboard event handling in the Synedit component, which is used for the source code editor. But it is buggy as well.

davidbannon commented 3 years ago

For the record, I can demonstrate this problem using just a TMemo, its absolutely not a KMemo thing. I have posted a project to demo it on the FPC/Lazarus bug report.

Davo