I’d like to clarify one thing about this series of articles first. All features described in this series are already implemented, because I do not fell comfortable about writing about vaporware. The purpose of this series is to share some interesting experience during the development that might be useful to other people, so it may describe user invisible changes and uninteresting technical details.
Focus is an important concept to input method. In old Fcitx 4 world, fcitx 4 assume that you may only have one focused input context. And this is gonna changed in Fcitx 5.
There used to be an interesting feature request about using Fcitx on different X11 screen (In old days when xrand or xinerama does not exists). But the problem is you can not do that because it is not possible to open multiple connection or use different screen. The window of GUI must be created separated for different display.
And now things may change in Fcitx 5. Because we will end up with two display server at the same time, so why not support multiple X server too 😛 ?
In Fcitx 5, every input context will have a property about its display. And every display has a new concept called focus group. In Fcitx 5, there will be at most one input context in the same focus group.
Also, one important thing about multiple display support is that, the GUI also need to handle multiple display. As I already stated in previous post, the wayland im protocol will NOT work with X11 client. X11 client must keep using XIM/IM module. Thus X11 window is even necessary for display Input method window under Wayland for Xwayland client. The display server information in input context will also help UI to decide how to display UI for the application in different Display.
Also, Fcitx 5 will use more input context specific state because the many API is now forced to pass a relevant input context. So, although unfocus will still trigger reset (IMHO that’s a reasonable thing to do), the under-hood states are separated instead of shared.
One interesting technical detail about DBus based client is that, we need to put DBus client in to the right focus group. In order to do that, the im module will now send a X client message to a special Fcitx X window to indicate the actual focus group of display server that it wants to join. The message contains a UUID generated by Fcitx. And client will send this UUID back to the fcitx window. If fcitx recognize this UUID, it will put the input context in the corresponding focus group. In this way, we avoid matching DISPLAY env var because it not always reliable. For example, DISPLAY=:0 and DISPLAY=:0.0 may not have visible difference to the client, but if we match it based on $DISPLAY, it is hard to say if these two display are the same display. But by sending the client message to current connected X window, we will always send message to the right X server.
See you next time 🙂 .
P. S.
Also, if you find my work helpful to you, feel free to buy me a beer. The donation link can be found at https://www.csslayer.info/wordpress/donation/ .
