Actually there is nothing so special about this feature, it’s just come freely with the multiple X server support. I just realized that WAYLAND_SOCKET passed from compositor can be just sent via DBus to the actual fcitx5 server, without the need to let compositor start Fcitx 5 directly. There will be a new small tool included in the next release (fcitx5-wayland-launcher). It can be used to initiate a new wayland connection from Fcitx, even if WAYLAND_SOCKET is required to be used link kwin or weston.
Some people may find it useful if they want to keep Fcitx as a user-level daemon. I didn’t test it, but I think this is what can be done:
Remove all other method of auto start mechanism.
create a user systemd unit, with command fcitx5 -k. The “-k” allows fcitx 5 to be kept running even if display server is gone.
Make your X11 or wayland desktop to run a command to start a new X connection or Wayland connection.
Fcitx 5 first release is in 2020/11/2, and as of today, we have reached the 13th release of Fcitx 5.
What happened to Fcitx 5 within this whole year of development?
1. Best Wayland support on Linux
As of today, to my knowledge, Fcitx 5 is the only input method frameworks under Linux that works under all different types of wayland.
We have been testing KDE/GNOME/Sway (Only causally played with wayfire and since there are too many wlroots based around we can’t do much test there.).
2. New engines
By the end of year we have two new engines https://keyman.com/ and https://github.com/OpenBangla/OpenBangla-Keyboard .
3. Flatpak support
Not only flatpak support fcitx5, but fcitx5 also works as a flatpak package.
4. New features comparing to Fcitx 4 counterparts.
We really got tons of them new features, e.g.
fully customizable shuangpin profile (you can define shuangpin profile with any combinitions of initial/final
new preedit mode that takes less space in input window
punctuation configuration via GUI
quick match for long word in Pinyin
paritial shuangpin support
rime plugin loading
rime new preedit mode
rime dbus API
rime app_options
…
5. Android support
I didn’t develop this, only provides some Q/A on the details, and add some support to make it build/work on android more easily. https://github.com/rocka/fcitx5-android-poc/ It’s still considered as highly experimental, please use it with caution. One of our next target is to come up with a new API for implementing virtual keyboard, which will also benefit the native linux on screen keyboard.
If you are still using Fcitx 4, please consider give Fcitx 5 a try. You can find the distribution that packages fcitx5 via https://pkgs.org/search/?q=fcitx5 .
This is mainly a complain about how mess this feature is and why no one could reliably use it.
To give people some background, surrounding text is about the feature that an application can notify the input method what are the characters around the cursor, and the input method can directly change the text around the cursor.
For example, in a input box, you have some text like this.
With surrounding text, application is able to notify input method the context around the cursor.
For example, in this case, the input method will receive text is “I like typing.”, the anchor is 8, and the cursor is 10. Anchor is the starting offset of the selection, and the cursor is the end of selection. If there is no selection, anchor will equal to cursor.
Now you may want to ask, isn’t it a costly thing to do? Answer is YES. Imagine you have a crazy long line in the editor, and whenever you change the text, you will need to send it over to the input method. Usually, input method would just apply a maximum size.
Next we will need to talk about the messiest thing about this is the API. Here lets list things about what are people doing with it.
Gtk native API: set_surrounding_text / delete_surrounding_text, the value of offset is Unicode(UCS4) character based. delete_surrounding_text uses (offset, length) to define the range.
Qt native API: the value of offset is UTF-16 character based. delete_surrounding_text uses (offset, length) to define the range, but, it excludes the current selected text when applying offset and length.
Wayland protocol text-input-v1 / zwp_input_method_v1, similar to Qt, but offsets are UTF-8 character based.
Wayland protocol text-input-v2 / text-input-v3 / zwp_input_method_v2 , delete_surrounding_text uses (before, after) to described the range. Basically it means some additional character before and after the selection. Offsets are also utf8 character based.
Gtk implementation of text-input-v3 (?!), does not follow (4), by just using received UTF-8 offset as Unicode (UCS4) based offset, which is actually a bug. Also, it does not actively sending over the update of surrounding text, which makes it useless.
Also, people seems to not have a clear definition about whether surrounding text should include preedit text. Which is purely headache to deal with.
Not to mention that non-native widget implemented with Gtk/Qt are very likely to implement it in a wrong way. Also XIM does not support it. Not to mention that terminal application that does not support it have to claim it support surrounding text, due to lacking of ability to notify application.
So now, people are more likely to stick to use a limited set of feature in surrounding text.
Use it as auxiliary data like primary selection, to just learn about what text is being selected.
Delete surrounding text only when it is extremely reliable, e.g. delete 1 cursor before cursor.
When implementing a feature that requires full featured surrounding text, make this feature optional and always provides an alternative easy way for user to not using it.
When Fcitx read the layout information, it read from xkeyboard-config, mostly like to be /usr/share/X11/xkb/rules/evdev.xml on your system. But unfortunately, there might be missing data in this file and you should report the bug to bugs.freedesktop.org for missing data.
But what if you want to use the layout right now without waiting for the bugfix for xkeyboard-config?
Here’s an easy way to do it at user level.
For example, if you use setxkbmap -layout br -variant abnt2 to setup your keyboard input method, but you find this entry is not currently in evdev.xml files, then you can do:
1. Create a configuration for input method Pleasse notice, the file name matters, it should be named by keyboard-[layout]-[variant].conf The file name for this layout should be ~/.local/share/fcitx5/inputmethod/keyboard-br-abnt2.conf
The “Name=” section in the file doesn’t really matter, you can put anything meaningful to you. LangCode= and Label= also doesn’t really matter.
2. Restart fcitx 5 to make it reload the data.
3. Open config tool to add it to the list.
4. Move it to the first place in the list, and you will get a popup that ask you: whether you want to fix the config to make the system layout configuration matches the first input method. You may click yes to set it. Because evdev.xml does not have the corresponding entry, you’ll not be able configure the system layout the regular way.
Then you should be able to use the layout just like using the setxkbmap command, enjoy!
