-
Notifications
You must be signed in to change notification settings - Fork 278
implement text-input and input-method protocol support #12
Conversation
This is mostly copied from the sway implementation here: https://github.com/swaywm/sway/pull/4740/files
0fe044c
to
7e1e931
Compare
I have wanted to give an update on the current state of this PR since I have tried to implement input-method V2 in ibus here Luckily I have found https://github.com/tadeokondrak/anthywl Note that this is (quite) a lot of code to implement functionality Given that the area of input methods on Wayland is still very much What do you think? |
@Shugyousha , i cloned https://github.com/Shugyousha/dwl/tree/input-protocols , but it failed to make, i guess i might be incompatible wlroots version, could you please let me know what version of wlroots to work with? |
Hi
guyuming ***@***.***> wrote:
@Shugyousha , i cloned
https://github.com/Shugyousha/dwl/tree/input-protocols , but it failed
to make, i guess i might be incompatible wlroots version, could you
please let me know what version of wlroots to work with?
I just tried to compile dwl on my machine using the newest git and non-git
version of wlroots that is available on my Linux distribution. Neither
the git nor the non-git version of wlroots made dwl (main or wlroots-next)
compile on my machine for me.
Since this PR is quite old, I would expect that we would need to rebase
my changes on top of a more up-to-date version of the dwl code before
we can start to get this compiling again.
On the positive side, the PR swaywm/wlroots#2550
that you had to apply manually to wlroots in order to get the necessary
protocol support in wlroots has been merged. That means you don't need to
compile your own patched version of wlroots anymore to get this running
(once this PR has been rebased on the current HEAD and everything is
compiling again).
That said, I am not sure I will be able to find the time to rebase
this PR at the moment ...
|
i tried:
it compiles fine. but if i try:
it prompts compile error. i guess i should enter the wlroots folder and git checkout some_commit_id and reinstall, the some_commit_id can be that you compile your code with when you made the pull request. but i don't know what is the some_commit_id. |
guyuming ***@***.***> wrote:
> I just tried to compile dwl on my machine using the newest git
> and non-git version of wlroots that is available on my Linux
> distribution. Neither the git nor the non-git version of wlroots
> made dwl (main or wlroots-next) compile on my machine for me.
i tried:
```
git clone https://gitlab.freedesktop.org/wlroots/wlroots.git
cd wlroots
git checkout 0.15.1
meson build/
sudo ninja -C build/ install
cd ~
git clone https://github.com/djpohly/dwl.git
cd dwl
make
```
it compiles fine.
I checked this on my machine and it looks like my "config.h" was either
too old or broken. Updating and fixing it made the compilation work
(using wlroots 0.15.1).
but if i try:
```
git clone https://github.com/Shugyousha/dwl.git dwl-ime
cd ~/dwl-ime
git checkout input-protocols
make
```
it prompts compile error. i guess i should enter the wlroots folder
and git checkout some_commit_id and reinstall, the some_commit_id can
be that you compile your code with when you made the pull request. but
i don't know what is the some_commit_id.
I don't remember the commit ID either of course but in theory you could
just choose a commit from around the time I opened the PR.
Note that then you have to add the patch from the PR manually that
has now already been merged upstream. Due to this, I think the better
approach would be to try to rebase the changes in my PR on top of the
current HEAD. Not sure how much work this would be though.
|
@Shugyousha I made changes to current dwl.c based on your pull request, and add text_input.c text_input.h files so that i can make changes to dwl.c as little as possible. i commented out most popups related code since i cannot pass compilation with them. But konsole works with fcitx5 on my machine now. However, other VTs such as foot and alacritty does not work with fcitx5. I wonder if it is related with the "popups" code. i have some technical issue with pushing to github, so i published my change here: https://gitee.com/guyuming76/dwl/tree/guyuming1 update: turned out i can input Chinese in konsole with fcitx5, no need for any change to dwl. with dbus-monitor, i can see that konsole communicate with fcitx5 via dbus, but alacritty don't. The problem is i change from xorg to wayland because i heard that in x, one window can get key event of another window. Now if we rely on dbus, will one window in wayland still be able to get IME input of another wayland window thought dbus message sniffering? |
@Shugyousha , your code now compiles fine on my machine: https://gitee.com/guyuming76/dwl/tree/guyuming3 . However, it gives sigsegv error as screenshot i put in fcitx/fcitx5#481 , when i press ctrl+space in alacritty to switch to IME. i think the problem is with the line 2595 in https://github.com/djpohly/dwl/pull/12/files :client = client_from_wlr_surface(surface) the left side of assignment is of type Client, while the right side is surface->data, which can be of type struct wlr_scene_node * I compare your input_popups_set_focus implementation with that in https://github.com/swaywm/sway/pull/5890/files , the problem of which is that the view_from_wlr_surface function implementation does not return anything! |
i seemed to make it work, that is, i can input Chinese in alacritty: https://gitee.com/guyuming76/dwl/commits/guyuming4 but i am facing sigsegv error with Xwayland unmanaged window, i have some screenshots here https://gitee.com/guyuming76/personal/commit/45d2e97adc98e483ef990cd45bcd5aca463a361b and i raised a question here: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3427 |
Hi
guyuming ***@***.***> wrote:
i seemed to make it work, that is, i can input Chinese in alacritty:
https://gitee.com/guyuming76/dwl/commits/guyuming4
I have started to rebase my branch on top of the current dwl main
branch. I can currently input Japanese using anthywl but I still have to
look into the popup rendering (no popups are yet rendered on my version
of the code. See below for the likely reason).
but i am facing sigsegv error with Xwayland
unmanaged window, i have some screenshots here
https://gitee.com/guyuming76/personal/commit/45d2e97adc98e483ef990cd45bcd5aca463a361b
and i raised a question here: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3427
To me it looks like the wlroots rendering API used in dwl has changed to
a (newer?) scene tree based one. From what I understand we will have to
change the current rendering code to make use of this new scene tree API.
I *think* that should be possible but it may take me quite a while to
figure out how this works so don't hesitate to make it work on your side
if you know how to do it!
Cheers and thanks for the interest!
Silvan
|
i just summarized my "rebase" here: (https://gitee.com/guyuming76/dwl/commit/f82c23c196e2c3f1d1997812bff473eae2a20a10 ), gitee now support github and gitlab account sign-in. |
I have rebased this code so it should work on Note that there are still issues but at least now the code compiles and works (mostly) again. Let's move all discussion to the new PR. |
This is mostly copied from the sway implementation here:
https://github.com/swaywm/sway/pull/4740/files
I have confirmed that with these implementations, dwl behaves the same as sway when we run the
input-method
andtext-input
examples of wlroots.I have tried to run other input-method implementations for testing but both https://github.com/emersion/wlhangul and https://github.com/xdavidwu/wlchewing depend on further protocols being implemented (both need virtual-keyboard protocol support and wlhangul some extra patches IIRC) before they can be tested.
I will try to prepare some more testing (I'm currently checking if I can manage to implement input-method V2 easily in ibus, see here ibus/ibus#2182) but until I'm done with that you can have a first look at the code.