sway
sway copied to clipboard
text_input: Implement input-method popups
May I continue this pr in https://github.com/swaywm/sway/pull/5890 ?
I'm not sure but I don't think this currently works at all? i.e. the original PR needs changes after https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3660 .
I'm not sure but I don't think this currently works at all? i.e. the original PR needs changes after https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3660 .
Emm, It seems still works with the wlroots master and sway master, and I also make changes with the suggestion of the maintainer..
@Decodetalkers Does the input popup correctly disappear after you commit some text?
@Decodetalkers Does the input popup correctly disappear after you commit some text?
I cannot understand, what kind of "uncorrect", can you show me a video ? I cannot reproduce anything..
https://user-images.githubusercontent.com/11485439/198550984-ea9fc638-dd3f-4ef2-8e21-e3dbd5b76f93.mp4
mov-2022-10-28--17-05-11.mp4
I see, I reproduced it on foot.. but wezterm do not have such problem.. Interesting..
mov-2022-10-28--17-05-11.mp4
Now it should be fixed
Does this show horizontal pop-ups or vertical pop-ups?
Does this show horizontal pop-ups or vertical pop-ups?
@amano-kenji This depends on your IME. The popup is rendered by the IME.
Is it going to be merged soon? It sems Hyprland already merged this feature.
This PR hasn't been updated for quite a long time, can someone please help to review it?
I havent found anyting outrageous here, is there anybody running this with valgrind and/or sanitizers to catch leaks?
As I checked with ASAN there is no leak. Do you need any sway.log?
I don't think this behaves correctly when the anchor (toplevel or layer surface) of an input popup changes (disappears or updates its position for instance).
after position changed
That bug occurs when it's moving from one monitor (scale 1) to other monitor (scale 2) for me. Tested with fcitx5
I don't think this behaves correctly when the anchor (toplevel or layer surface) of an input popup changes (disappears or updates its position for instance).
I try to fixed in the second commit, destroy the popup when every commit.. but I do not know if it is the right way to handle it
any update?
I've been using this patch on my Arch Linux for over half a year (via sway-im-git
AUR package). I think it's pretty stable now. Could we start to review this MR and merge to main branch?
Not sure if i'm doing anything wrong, but i'm still only seeing the fcitx5 popup on Xwayland apps -- for example, normal alacritty doesn't show but WAYLAND_DISPLAY= alacritty
does work (i.e. what sway without this pr does).
This is on NixOS, with this patch applied atop sway v1.8.1.
@ralismark What exact patch are you using? I don't think this patch applied as is on sway 1.8.1 builds on wlroots 0.16.x .
This is on NixOS, with this patch applied atop sway v1.8.1.
IMO this patch doesn't compile on sway v1.8.1. FWIW, there is a patch available on AUR that fits sway v1.8.1: sway-im.
@ralismark What exact patch are you using? I don't think this patch applied on sway 1.8.1 builds on wlroots 0.16.x .
oops, user error on my part -- was trying to modify the wrong package and it silently ignoring my changes. sorry!
Any updates for this? This is the only reason I can't migrate.
will someone could porting this to swayfx? i think fcitx will looks better on it: https://github.com/WillPower3309/swayfx
It's quite saddening to see IME support neglected like this. Typing various languages and typing emoji on non-IME-supported languages, having some basic spell checking and autocompletion is something we've been able to do on X11 for a long time, phones came with that from the start, software keyboards are also a thing these days on many devices and yet both the wayland protocols for it and WM support is lacking, not to mention app support. Unfortunately all layers need to support this properly. It's much more convenient to, for instance, just have fcitx quickphrases everywhere working the same way than dealing with multiple differently-working custom emoji pickers on messengers, websites, etc. But hey... with wayland it's all going to be better from the ground up without all the mistakes from the X11 past... Yeah right. 😒
will someone could porting this to swayfx? i think fcitx will looks better on it: https://github.com/WillPower3309/swayfx
I made a patch at https://github.com/natsukagami/swayfx/tree/im, it compiles and all, but I'm not sure if it's really working. Turns out I don't really need it for mozc
:P
will someone could porting this to swayfx? i think fcitx will looks better on it: https://github.com/WillPower3309/swayfx
I made a patch at https://github.com/natsukagami/swayfx/tree/im, it compiles and all, but I'm not sure if it's really working. Turns out I don't really need it for
mozc
:P
pretty thanks for your jobs! this patch works, and I've uploaded it to my gentoo's overlay
Bad news for this PR, the merge is blocked on the scene api (#6844) which will make most of the rendering/damage code irrelevant. We don't have an ETA for the scene graph merge (probably after the release?)
Patch works for me with fcitx5 on Alpine.
The input popup looks pretty blurry. Can someone confirm if this is an fcitx issue?
fctix.log: https://paste.sr.ht/~whynothugo/0f04e01d74d41a94663de0aab9c7ce313562dcc5