input-method-v1 #2172
input-method-v1 #2172
Conversation
|
@lilydjwg I have finished a first version of the im-v1 protocol. From my limited testing, it seems to work fine, including when changing between layouts, switchers, etc. But I am usually not using fcitx5 so I am sure I have missed something, please test when you have time and let me know what still needs to be fixed. |
|
That's really quick! I've done a quick test. Basic functionality works, but it has several issues, like restart fcitx5 crashes wayfire, and interaction with switcher & vswitcher plugins. I'll see if I can fix it. |
Restarting fcitx5 was easy enough to fix, I just pushed a commit. For switcher & vswitch, you're right. I tested it and it seemed to work but somehow fcitx5 doesn't work properly with chinese output after the switch, I have to toggle it to english and then back to pinyin and only then it works. |
|
I've resolved most of found issues (https://github.com/lilydjwg/wayfire/commits/im-v1/), except one: moving windows using vswitch. There is no focus change so key events are sent to the window despite vswitch handled it. |
|
@lilydjwg I am looking at your commits but IM keys should never go to plugins so I probably misunderstand a few things you changed .. Also force-release keys should not be done. When keyboard leaves a surface, the application is responsible for releasing all of its keys. This is also how it is done for normal keyboard switches (i.e if you have KEY_A pressed in app X, then switch to Y, Wayfire shouldn't send any release events) |
but then plugins won't receive keys as it's swallowed by this im-v1 plugin.
I'm trying to fix unreleased keys issue when im connects / disconnects (keyboard doesn't leave). It doesn't work anyway. Run |
Oh for this we'll have to track pressed keys by the IM, yes. We need a set of pressed keys in the im-v1 plugin, just like in core. |
Yeees but also no. The way it works is that the IM sets the processing mode to NO_CLIENT (for the physical keyboard event): which means that grabs and regular clients will not receive the key. But the event is not set to IGNORE, so core still processes it for keybindings. Also with the NO_CLIENT mode the plugin(s) will not receive the key press on its grab, but I changed switcher/fast-switcher to use the RAW_INPUT flag, which means they are also receiving release events even if they didn't get a press event (like is the case with fcitx5). Note that as soon as we grab the input, the input focus changes so the release event is not grabbed by fcitx5 anymore so those plugins can receive the release event properly. |
|
I see and have updated the commits. I don't know why but several issues have disappeared for me. Current issues:
|
|
Ok, thanks for testing. I can see what causees these issues and I'll try to figure out how to fix it in the best way. Maybe we'll need a new signal for IMs ... |
|
@lilydjwg I believe that I fixed the issues you mentioned. There are also automatic tests for all of them, the old -v2 implementation is not passing them, the new one does ;) https://github.com/ammen99/wayfire-tests/tree/master/tests/im Let me know whether you can find any other bugs. If not, we can merge this PR. |
|
@ammen99 You are sooooo diligent! |
|
All previous issues are gone, but I find a new one:
|
|
@lilydjwg That sounds like an fcitx5 bug to me, I don't see what Wayfire can be doing wrong to cause this. Have you checked the messages in the wayland protocol between wayfire and fcitx5 or between wayfire and whatever terminal/editor you're using? |
|
There is a missing |
That's a good point thanks :) Feel free to send a PR to this branch. |
|
I'll merge this PR when CI finishes, if you find any more bugs, feel free to send PRs of course ;) |
This prints in detail how we process keyboard key events.
This reverts commit 10fb8cb.
Only xdg-shell popups need the window geometry of their parent added to their position, im-popups are defined as surface-local coords.
It is still available if someone needs it but it is a gross hack currently, prefer the upcoming input-method-v1 instead.
This is needed for keyboard events, where the wlr event does not contain the information required.
This makes GTK to emit preedit-end signals so that vte paints its cursor. The preedit_string from input-method-v1 can't be null.
The implementation is very incomplete atm, hence the draft status.
I still need to figure out how to combine the data from input-method-v1 events and text-input-v3, because the latter uses slightly different format for some requests.