Mention that IME is not in usable state

[pickfire]

IME, Input Method Editor is used for asian to enter text.

There are a few IME but I think fcitx5 supports it but there are still issues. I think ibus and fcitx does not support wayland yet.

From what I recall, freedesktop have input proposal unstable input method protocol v1 but I don't think anyone is using that.

Sway have their own input method protocol v2 which is not in freedesktop but I think that is what others implements.

I haven't been keeping up with this but I don't think wayland is usable yet for anyone that needs IME.

[madblobfish]

Hi @pickfire, I'm running sway and ibus works perfectly fine for me and others, did not try fcitx. It's been supported since sway 1.5 See the following sway issues: https://github.com/swaywm/sway/issues/873 and https://github.com/swaywm/sway/issues/4841

[hukacode]

Hi @madblobfish Could you please share your config or how do you setup it?

[madblobfish]

@hukacode I do not know if this will help you, because I do not use a greeter as most others do. Anyways, here are the parts that made it work for me (I somehow needed a restart, sway restart might be sufficient, idk):

0. I use arch, so I installed all needed things for Japanese input with anthy by: pacman -Syu ibus-anthy
1. I use fish and start sway directly after getty with the following snippet (~/.config/fish/config.fish):

   if test (tty) = '/dev/tty1' -a -z "$DISPLAY"
       exec sway # -d 2> /tmp/sway.log > /tmp/sway.log
   end

2. ~/.config/sway/config:

   exec ibus-daemon -dr
   bindsym $mod+space exec sh -c 'if [ "$(ibus engine)" = "anthy" ]; then ibus engine xkb:de:nodeadkeys:deu; else ibus engine anthy; fi'

3. I use fish universal variables to configure the 3 required envs, you may use profile /etc/environment or whatever instead:

   set -Ux GTK_IM_MODULE ibus
   set -Ux QT_IM_MODULE ibus
   set -Ux XMODIFIERS @im=ibus

I did not find or remember anything else I had to configure. But some applications do not play well with it, for example sublime-text3 once worked, but is currently broken for me (I think this might have something to do with the newer protocol in sway). kitty has a configuration option to use ibus, but I prefer the default. Firefox where I need to write the most just works.

I can't provide more help, good luck. グッドラック

PS: fixed formatting bug. Also here's how the guy who started sway does it: https://git.sr.ht/~sircmpwn/dotfiles/tree/master/item/.config/sway/config#L146 No idea where he sets the environment vars or starts ibus though.

[hukacode]

Hi @madblobfish

Thank you for your supporting. I really appreciate it. I can type Japanese, Vietnamese on sway now.

Best regards, Huka

[jedahan]

@madblobfish this would be awesome to add to wiki or docs or contrib/ somewhere...

[madblobfish]

@jedahan Feel free to do so

[ghost]

In my case it works for GTK and Qt programs, but not "generic" programs, such as the foot terminal, or alacritty terminal.

Also, ibus has a very useful feature of adding emoji with suggestions, as well as typing charaters by their Unicode value. (Shift+Super+e and Shift+Super+u in my case).

Has anyone found a way to use those with Wayland/Sway?

[minhduc0711]

In my case it works for GTK and Qt programs, but not "generic" programs, such as the foot terminal, or alacritty terminal.

@lockywolf I think foot and alacritty use a newer input protocol so ibus does not work there. I tried xfce4-terminal and ibus does work.

[Madwonk]

For me at least, I've followed all the configs listed in various threads and still can't get a working configuration. Perhaps there's a specific issue with Pinyin? I have this same issue mentioned in 2019:

The pinyin selection dialog flashes in the upper left but goes away immediately for me. If I press space very quickly after typing my character, I can at least get the first match to be selected ... but given how Chinese works, that's pretty much useless—we really need to be able to scroll through the match list.

I've also noticed the same behavior when trying to use key combinations to switch between IMEs. Oddly enough, it does work on xwayland applications but that's not all that useful in my case.

Also worth mentioning, it's not a Wayland issue as everything works flawlessly under Gnome.

[jonassmedegaard]

No, it is deceptively inaccurate that everything works flawlessly under GNOME: GNOME supports IBus specifically, not IMEs generally. Some users of lightweight environments like Sway might want lightweight IMEs like fcitx5.

Similarly, beware that some applications experienced working may be due to bypassing Wayland either via GTK, Qt, or Xwayland.

GNOME support is implemented through Wayland input-method v1. Some alternatives including wlroot-based environments like Sway use Wayland input-method v2.

Overview of involved Wayland protocols

IBus issue and draft code with plea for help

Hints on escape sequences to enable IBus in foot, supported since v1.6.0 (as build-time option, so check that your build of foot actually supports it before pulling hair out).

[jonassmedegaard]

Wayland protocol issue tracking consolidation of input protocols

[jonassmedegaard]

For interacting with IMEs each environment may need additional support for placing its popup dialog - e.g. Sway may(be still) need the patch mentioned here

[jonassmedegaard]

IBus panel is not yet supported for Wayland and should be disabled, instead switching engine using explicit calls to ibus engine.

[Blub]

I guess not a lot of people think about this: IMEs aren't only for asian text, you also get a lot of extras like emoji support without every GUI having to implement their own version of it (it makes a lot more sense as an IME, you also get this on phones with whatever software keyboards you install there...). With fcitx5's quickphrase I can just hit a hotkey and type :rocket: to type a 🚀, but for this to work well enough we need popup support. Sway still lacks this :-(

[RyanGibb]

For interacting with IMEs each environment may need additional support for placing its popup dialog - e.g. Sway may(be still) need the patch mentioned here

That patch works for most applications, but a notable exception is electron-based applications https://github.com/electron/electron/issues/33662