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

Inconsistent behavior comparing to scim-anthy #15

Open
wengxt opened this issue Oct 19, 2024 · 2 comments
Open

Inconsistent behavior comparing to scim-anthy #15

wengxt opened this issue Oct 19, 2024 · 2 comments

Comments

@wengxt
Copy link
Member

wengxt commented Oct 19, 2024

Quote from twitter reply:

Tank you very much. I will describe my environment and configuration, then explain a expected result and a actual result.

My environment:

Distributor ID:Ubuntu
Description:Ubuntu 24.04.1 LTS

fcitx5-anthy:amd64 5.1.3-1build2

My config:
I always use a extra-ordinary Nicola typing method in a ordinary OADG 109A keyboard.

Let's run a "Fcitx 5 Configuration."
Click the "Addons" tab in the "Fcitx Configuration" window.
Click the "Anthy [Configure]" in the "Input method" section in the addons tab.

"Typing method:" is "Nicola" in the "General" section in the "Anthy -- Fcitx Configuration" window.

In "Key" section, I set "Left thumb key:" is "Muhenkan" key.

The "Muhenkan" key is common key on Japanese keyboards. Maybe a "Space" key could be used instead.

Expected result:
In this configuration, if you press the "Muhenkan" key and "A" key at the same time, a character "を" (Wo) should always be entered.

Actual result:
However, after pressed "Convert" key (that is, candidate window is being displayed), you see "う" (U) character.

This behaviour is not seen in scim-anthy. In scim-anthy, "を"(Wo) is always entered when these two keys press at the same time, regardless of whether the Han Zi conversion candidate window is displayed.

If you press the "A" key first (even for a micro second), then press the "Muhenkan" key, the character "を" (Wo) always be entered in both environments (fcitx5-anthy and scim-anthy).

@wengxt
Copy link
Member Author

wengxt commented Oct 19, 2024

I suspect it might be relevant to the nicola timer, but I'm not sure.

Can you try to increase it to 1000 (maximum allowed value) and see if it helps to workaround your issue?

Also, another thing that might be useful for debugging is

  1. Run journalctl --user -f /usr/bin/fcitx5 , make sure you can see some log. If, so , keep this command running, and run another command bellow
dbus-send --type=method_call --print-reply=literal --dest=org.fcitx.Fcitx5 /controller org.fcitx.Fcitx.Controller1.SetLogRule 'string:key_trace=0'

This should make the previous command to produce a new line on every key being sent to fcitx5

  1. If you don't see anything from journalctl --user -f /usr/bin/fcitx5 , then probably you'd try to restart fcitx by yourself in the terminal. Run fcitx5 -rd --verbose=key_trace=5

Both should let you see some log line like:

KeyEvent: Key(Return states=0) rawKey: Key(Return states=0) origKey: Key(Return states=0) Release:1 keycode: 36

Next, try to reproduce the issue you describe, and try to align it with the log being printed there (you can put two window side by side, so you know which line is being printed while you typing )

Thanks

@wengxt
Copy link
Member Author

wengxt commented Oct 21, 2024

The issue seems to be relevant when candidate window is shown. Per https://x.com/nekodesuka5/status/1847711441559994486

Also, there seem to be some conflict if convert key (next candidate?) is same as thumb key.

wengxt added a commit that referenced this issue Oct 23, 2024
Prepare for investigating #15 issue
wengxt added a commit that referenced this issue Oct 23, 2024
Prepare for investigating #15 issue
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

No branches or pull requests

1 participant