Unicode input problem under wayland

[Mo_Al_]

Hello

I would appreciate insight regarding the following issue, which was reported at fltk-rs, but I think the issue lies in the IME support under wayland:
https://github.com/fltk-rs/fltk-rs/issues/1539
The link contains a video showing the behavior. 
The fltk-rs version this was reported against is 1.4.28, which corresponds to FTLK revision 1bc568047250a39dc5cd60eac49f40d36fe82201(from 2 weeks ago).

When I input ASCII characters, as long as the frequency is a little faster, repeated characters will appear.
For example, "hello world" will become: "heeellllllooo wwooorrrlld".

When I input Unicode characters, there is a high probability that the characters will be garbled, and sometimes the input characters will disappear.

The most outrageous thing is that sometimes it triggers the string to "flicker".

In the video above, it looks like I’m constantly deleting text, but I’m not. I just typed emo.

Note: Only wayland triggers this issue, x11 does not.

This issue has rendered the input method of Wayland basically unusable, I hope it can be fixed.

• OS: Debian Sid GNU/Linux (x86_64)
• Display: Wayland
• Desktop: KDE Plasma 5.27.10-1+b2
• 
  
• (process:160445): Pango-WARNING **: 22:53:29.310: Invalid UTF-8 string passed to pango_layout_set_text()
  

[Manolo]

Le dimanche 21 avril 2024 à 03:32:43 UTC+2, may64...@gmail.com a écrit :

Hello

I would appreciate insight regarding the following issue, which was reported at fltk-rs, but I think the issue lies in the IME support under wayland:
https://github.com/fltk-rs/fltk-rs/issues/1539

The issue discussed involves an Input Method for Chinese text. Is it possible that fltk-rs is somehow unable to accomodate the new player when such an IM is used? Please, pardon this question if it's stupid. I don't know what rust is and how fltk-rs works at all.

Such IM opens an auxiliary window that captures the focus from the current FLTK wayland window and later feeds the wayland window with Chinese text and closes the auxiliary window.

[Mo_Al_]

Thank you for having a look at this, and I appreciate your input in the linked issue.

Normally fltk-rs just does some setup code at the start of an application (to initialize boxtypes since boxtype macros can't be wrapped, so this is done in cfltk).

Widget instantiation code is passed as is to FLTK, except for labels since Rust doesn't deal with null terminated strings, so a null terminator is added if there is a label. fltk-rs widget methods are mostly thin wrappers, except for some arguments again like null terminated strings.

fltk-rs doesn't run any shutdown code. During the build it patches (disables) some FLTK shutdown code on windows since it interferes with Rust's shutdown code.

Regarding widget behavior, there shouldn't be any difference since these remain internal to FLTK. 

As for Rust itself, AFAIK it doesn't do anything extra on startup since it has no static initialization or global constructors, vtables and such. 

It zeroes some registers, aligns the stack, calls a dummy main to get the command line args, then starts its main function which is stored as a function pointer in an executable's stack.

As far as IMEs go, when the issue got posted I made a quick search and found similar issues for wayland:

https://bbs.archlinux.org/viewtopic.php?id=284900

https://github.com/microsoft/vscode/issues/168025

https://github.com/alacritty/alacritty/issues/5065

[Manolo]

Le lundi 22 avril 2024 à 23:21:34 UTC+2, may64...@gmail.com a écrit :

Thank you for having a look at this, and I appreciate your input in the linked issue.

……

Regarding widget behavior, there shouldn't be any difference since these remain internal to FLTK.

Thanks. That's also my conclusion after several interactions with the author of the fltk-rs issue #1539.

We are progressing, and I'm hopeful things can be improved. I know nothing about CJK writing systems

but I'm willing to have IM work correctly in FLTK under Wayland. I'm glad to be interacting with a user

of such IM.