Implement text-input and input-method protocol support, v2 #235
No reviewers
Labels
No labels
A: maintenance
A: question
B: not applicable
B: not reproducible
B: resolved
C: multi-DPI
C: protocols
C: rendering
C: XWayland
Kind/Bug
Kind/Feature
Reviewed
Duplicate
Reviewed
Won't Fix
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
dwl/dwl!235
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "Shugyousha/input-protocols-v2"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is a rebased version of https://github.com/djpohly/dwl/pull/12. Using
anthywlandwlroots0.15.1 you should be able to input Japanese and see the input popup as well.Note that there still some issues like the input popup position not updating properly when changing the layout while the popup is shown. If we decide to include this functionality in dwl, it's probably worth investing more time to figure out how to make this work properly.
Until then this code is mostly here so people can experiment with IMEs and their functionality in dwl (at least until these
text-inputandinput-methodprotocols get fixed and more stable; see the old PR mentioned above for details).see Shugyousha/dwl#1
hm, I must have totally missed that one last year for some reason ...
personally, I am not a fan of the "nospacesstyle" because it makes things harder to read in my opinion (I was actually contemplating to discuss opening a PR for dwl to change everything to snake_case ...). If djpohly prefers this style though, I can change it.
I think the same, but it comes from the dwm style
This is included below.
@ -28,3 +29,4 @@#include <wlr/types/wlr_input_inhibitor.h>#include <wlr/types/wlr_input_method_v2.h>#include <wlr/types/wlr_keyboard.h>#include <wlr/types/wlr_layer_shell_v1.h>No need to reorder.
This is not used anymore.
double blank line.
This funcs, are not needed, and also
client_from_wlr_surface()will crash if you send a wlr_surface that is a xwayland surfaceuse the
LISTENmacroThe same as above
The same as above
Use the
LISTENmacroIs really necessary add a listener for this?
This is never freed.
@Shugyousha , i works on my machine. I think what follows is the magic lines
And all those popup->link , popup->view_link lines of code are useless now, and we may remove them, right?
@Shugyousha , just found some issue:
Issue 1:
when i open alacritty in tag 1 and press Ctrl+space to switch to Chinese input, its fine;
but then i press Alt+2 to switch to tag 2, and continue to type, there will be input popup in tag 2, notice thitat currently, there is not application open in tag 2 yet, and the committed Chinese input will appear in the alacritty in tag 1.
Issue 2: it might be related to issue 1: i switch to a new tag, open alacritty in new tag and input some Chinese , then i go back to the original tag, sometimes, i cannot switch to Chinese again in the original tag. I have not found the exact procedure to reproduce this, but by switching to new tag and switching back, chances are that you might lose the ability to turn on input. However, after some switching between tags, you can have input popup again.
May be solved assigning tags to input popups, or even better popups should be children of the clients.
to reproduce issue2, xwayland in config.mk needs to be enabled.
So, are you running alacritty through xwayland?
I suggest keeping one piece of the code above commented as sample bellow the LISTEM macro definition. It took me some time to understand what the LISTEN definition mean. And those code which don't use the LISTEN macro helped me to understand at last.
I don't think so.
if i run xwininfo, and then click a geogebra window, it will return xwindow information;
but if i run xwininfo and then click an alacritty window, nothing returns.
Any other way to check whether alacritty runs through xwayland?
xeyes
popups should be children of the clients. Does this mean that children can only be shown inside the client rectangle? what if the client rectangle is very small?
assigning tags to popups. Sounds fine. But, when i switch to an empty tag, there is no popup at first. After i press a key, the popup appears in the empty tag. The problem seems to be why my key press has been routed to the previous client(or text_input associated with that client or anything else. I am not sure about the underlying process, have not traced the code yet) while i am now in an empty tag. When i leave a client to a new tag, no key press should be routed to the client as i understand. And my test to DWL without text_input works as expected. I mean, i am not sure whether this is cause by text_input and input_method or their usage in this PR
The current behavior: constrain popups to monitor size
Sounds like a bug of this implementation, we should check this and keyboard_get_im_grab()
after some debugging, i find that:
And if this can be done, why not just suppress the key in the following wlr_input_method_keyboard_grab_v2_xxxxxxx method calls due to some client surface is not activated?
And in step 1, wlr_seat_keyboard_notify_clear_focus are called in focusclient if no client, but it does not seem to have effect on input_method->keyboard_grab. I am not sure about what keyboard_grab mean, but why wlr_seat_keyboard_notify_clear_focus don't prevent input_method from accepting key here?
Anyway, i tried a simple but "brutal" fix here:
guyuming76/dwl@3e55353b3d, which seems to fix Issue 1 i mentioned above. But issue 2 still exist. Actually, i still have no idea about what cause issue 2.By the way, creating popup in layers[lyrFloat] seems to conflict with existing floating window features. If i press MOD and drag an alacritty window to float, input method popup won't appear in that window.
UPDATE: found a better fix for issue1:
guyuming76/dwl@342f9658caUPDATE: looks like the cause of Issue2 i mentioned above can be "fixed" this way:
guyuming76/dwl@1edd23d818. But this will crash DWL when press key in a tag with no client. The question is, no way to disable a specific text_input in wlroots?UPDATE: to my surprise, this seem to fix Issue2:
guyuming76/dwl@6fd7a417f5Not a fan of the macro either but I have changed it.
I think it makes sense to make the initialisation consistent so I will change it everywhere.
If you prefer I can call
wlr_xdg_surface_from_wlr_surface(surface)->data;directly?AFAICT this function is only used for the input text protocol handling so I don't think any XWayland surfaces are able to be passed to this function. Not 100% sure about this though.
I assume that the Wayland protocol requires that the state is updated when a
commitrequest is sent.When I removed the code and made the handler a no-op, it didn't seem to make a different when doing some light testing ...
Yes, I think so. I have removed them, thanks!
i am curious why wlr_input_method_v2_send_deactivate(relay->input_method) and relay_disable_text_input are needed. So, i tried removing them (https://gitee.com/guyuming76/dwl/commits/PR235_5) . It works except that DWL crash if i try to input Chinese in geogebra (xwayland). But i still does not understand why.
why did we call input_popup_update so often? i removed most of them and have not got error yet: (
guyuming76/dwl@1cd75e7706)See https://github.com/djpohly/dwl/pull/235#discussion_r877658137
I pushed a replace for this function.
just found a new issue (call it Issue3 hereafter): with sloppyfocus=0, when i click into the Chinese input popup, dwl crash.
if sloppyfocus=1, dwl crash as soon as i move mouse onto the input popup, which i never noticed before,although i also had never paid attention to the sloppyfocus setting.
UPDATE: fixed with a new separate layer for input popup:
guyuming76/dwl@79fd6df77dI don't quite understand the difference between surface->role_data->data and surface->data->data ; but since i find in the creation of Client, surface->data->data is used, i think use the same in client_from_wlr_surface make sense.
I merged recent changes from dwl here: https://gitee.com/guyuming76/dwl/tree/PR235_7
@Shugyousha @Sevz17
input method suddenly stopped to work on my machine: the popup does not appear anymore.
So i added some wlr_log entries to help troubleshooting: https://gitee.com/guyuming76/dwl/commits/PR235_8
The log shows that input_method->keyboard_grab return false in function keyboard_get_im_grab.
but i don't know why this happens.
In wlr_input_method_v2.c , input_method->keyboard_grab is initialized in im_grab_keyboard, but i don't know what triggers im_grab_keyboard.
any suggestion?
UPDATE: turned out a silly mistake,i fixed it with:
guyuming76/dwl@7ad12a9aaaI have merged your changes and used the function you added, thanks!
This should be fixed now that I have merged your changes.
input_popup_updateupdates the popup state and also callswlr_input_popup_surface_v2_send_text_input_rectangle. The latter will send thetext_input_rectangleevent to the input method v2 client. AFAIK anthywl is not processing this event but in theory another input method implementation could depend on it being sent.I have changed the code to use its own layer for the input popups. I assume that this will fix this issue.
@Shugyousha @Sevz17
recently, i added support to onclick in my waybar custom module, so that i can use mouse click to switch between tags, besides the MOD+num keypress. it works by running "wtype -M alt 2 -m alt" command on mouse click.
And i got sigsegv exception as in screenshot:
so, i tried to fix in
guyuming76/dwl@226155c196not sure whether the fix is correct, anyway i don't have the sigsegv exception now.
@guyuming76 Where is your custom waybar module hosted?
@fauxmight
I put the files for my waybar here, if login is required, github account is supported: https://gitee.com/guyuming76/personal/tree/dwl/gentoo/waybar-dwl
And the README here https://gitee.com/guyuming76/dwl include my guide to start dwl with waybar.
@Shugyousha @Sevz17
I made a new change:
guyuming76/dwl@1df4b18d7fto address an issue which may reproduce as follows:
With this change, i don't have the issue anymore, the change is notdeactivating and activating input_method again and again, instead, only activate input_method only once on new. And the change is only for situation where XWAYLAND is not compiled in.
I have pushed a change to add a list of input popups to the Client and used it to deactivate the popup scene if the client is not visible on a tag.
@Shugyousha @sevz17
when i open search engine in firefox, such as bing and baidu, and enable text input in the search box and type, very often, the input popup will appear outside the firefox window, at its upper left hand, instead of below the cursor.
after adding wlr_log entries, i found that it is related to the cursor_rect in input_popup_update method, when the WLR_TEXT_INPUT_V3_FEATURE_CURSOR_RECTANGLE is not set.
is it a wlroots problem or not?
I think if the text-input implementation used in the client (so firefox in this case) is not sending this information (in time?) this feature flag will not be set and the dwl implementation cannot get the cursor position. In that case the popup
xandycoordinate will be set to 0 and the popup will show up in a corner.@Shugyousha
thanks! in my log, i can see the call to text_input_set_cursor_rectangle shortly after input_popup_update, but i don't know how to double check in code whether this is due to the client(firefox) or wlroots.
Anyway, i make a change to input_popup_update here:
guyuming76/dwl@c5019437caWhen !cursor_rect, i set
popup->x=parent.x;
popup->y=parent.y;
popup->visible=true;
That is, show popup at upper left corner of the parent surface.
Before the change popup->y will set to some negative value.
Many lines of code seems involved in this change only because they are indented after being added into the if (!cursor_rect) else branch.
@Shugyousha , what do you use for Japanese IME?
I tried fcitx5 with fcitx5-anthy these days, but it is NOT working normally,although:
fcitx5 Chinese works with this PR;
fcitx5 Chinese works with DWM;
fcitx5 Anthy works with DWM;
With Chinese, in both DWM and DWL, there is only one kind of popup for input.
With Anthy in DWM, there are two kinds of popup for input, one displays your type-ins, and the other(which appear after you press space) let you make selection.
But with Anthy in this PR, the first kind of popup won't appear, only the second appears.
I was using https://github.com/tadeokondrak/anthywl for testing. From what I remember, there is only one popup for this one.
does anyone still working on this? I'm an user who really need to type asian language and love dwl.
The patch seems to work fine in most cases, but one issue is that when I use (Mod + cursor) to move two floating Windows that support text-input (such as two terminals), after I have moved the first window by holding down the Mod key, If you continue to move the second window without releasing the mod key, you will find that it cannot be used at all.
Through debugging, it is found that when executing this code , the status of all mod keys will be automatically clear, regardless of whether you continue to hold down the mod key.
I studied it for a long time, but I couldn't find a solution.
the code line in the line 2627 which in function
dwl_input_method_relay_set_focus.Can someone help, please?
@DreamMaoMao I have tested this using two alacritty terminals and cannot reproduce the issue. What specific terminal are you using that has this issue?My mistake. I was testing without the patch applied.
i use foot terminal.
My mistake. I was testing without the patch applied.
how can I fix this update for wlroots,
@DreamMaoMao wrote in #235 (comment):
fix by add the four line code
I see that the readme says this will be considered "once ibus implements input-method v2." As the latest ibus release candidate claims support, are we interested in revisiting this?
I've had some success adapting the patch for dwl 0.7 (LaKato/dwl@edfc90ef94), and it appears to work with anthywl (with occasional issues with the popup like not always appearing), as well as both anthy and mozc under fcitx5 (no popup issues), though I haven't yet tried ibus.
I papered over a segfault in
arrange()from referencing a popup'sscenemember before it's set, though I suspect it could be solved more properly. I've also realized that moving the cursor over the popup (I think specifically bringing it into focus) is causing a segfault when callingwl_list_remove()infocusclient(), though I'm yet to fully understand or resolve it.If we still want to support these protocols (either in mainline or a patch), I'd be happy to work with someone to test and resolve remaining problems.
the pr is broken
if you want a 0.7 version
you can refer this:
guyuming76/dwl@d40b3d6ef1@LaKato
@DreamMaoMao wrote in #235 (comment):
I am aware, which is why I've tried updating it. If there is no intention of pursuing these protocols further in this thread, I'd like to suggest closing this PR and removing the reference to it from the dwl readme to avoid misleading anyone.
I haven't tried this out, but I can see that it's explicitly described as not working. Unless the "not working" part only applies to the handwriting functionality (which my update does not include), it sounds like my update is more functional (except for the noted crash when focusing the popup window). It's allowed me to use both fcitx5 and anthywl on Qt6 and GTK3 applications (I haven't tested other versions) as well as on foot terminal (which uses neither, of course).
@LaKato wrote in #235 (comment):
it work well with me , No problems, no crash.
You can try it out and notice the fixes in the next few commits, the one I gave you doesn't seem to be the final commit yet .
the work is base sway work in text_input,You can check out the source code for sway, they're pretty much the same.
.
@DreamMaoMao wrote in #235 (comment):
Ah, I missed that there were other commits afterwards. Thanks for pointing that out.
If we have IME support working, then, where does that leave this "feature under consideration" as mentioned in the readme? Do we want to try merging this into dwl (I imagine this is unlikely, but the readme suggests it's a possibility), or perhaps someone would be willing to submit this to the patches repository?
If nobody else is interested in doing so, I'd be fine with taking responsibility for maintenance of a patch.
Since DreamMaoMao deleted his comment and repository I'm reposting his patch. I'm not sure about copyright compatibility since it says GPL 2 only but it works great if someone wants to apply it.
You need to use
events.text_inputon wlroots 0.19 andevents.new_text_inputon wlroots master.View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.