The Standard Screen

こんにちは、私はコリンです。よろしくおねがいします。

So… I decided this blog will also be a place for me to post rants. So lets start. I speak 4 languages: English, Spanish, Mandarin Chinese, and Japanese. 2 of those 4 use a non Latin character set, so I have to use input methods to type characters in those language. This is not just relegated to far eastern languages, but ones like Russian and Arabic too. Input methods have long been the way to type in these languages, mostly because it solves the problem of “how do we translate this language into a set of keys to easily type on a keyboard.”

A language like Chinese is ideographic, which means it was never meant to be typed, but drawn. While a few Chinese keyboards do exist for typing by “creating” characters from strokes printed on the keys, its much easier to learn Pinyin, the Romanization of the pronunciation, and learn to type that way. However if all chinese was typed that way, we would get sentences like “wo shi xue sheng” rather than the actual Chinese characters “我是学生.” Not to mention, since chinese has many homophones, like “是 – shi – to be” and “十 – shi – the number 10” however the first is pronounced as “shure”, and the second as “shee” thanks to the tones attached to them. (In Pinyin, there are marks to denote the tones, but to type those you ALSO need an input method.) Thankfully input methods exist to take the Pinyin you type into account and turn it into characters that fit into context.

Now all of this sounds like a net positive, and for the most part it is. Both Windows and MacOS have built in support for input methods which are easily accessible from the settings, and Google implements a really damn good one into all Google web apps. But Linux… well… they kinda work on Linux.

In all fairness, I have used input methods on Linux for the better part of almost 5 years now. Originally just to convert my QWERTY keyboard into Dvorak (another good use for input methods), but more or less now to convert typed Chinese and Japanese into their correct written form. For the most part, both major input methods, FCITX and IBus have worked alright, however now we are in the transition between GTK 3 and GTK 4, along side the transition from X11 to Wayland. This transition has truly thrown a spanner into the works for the input methods, and just goes to show what Linux needs is more of a stable backbone instead of the module fluid system that exist now.

In Linux, both IBus and FCITX seem to hook into the application’s text input, rather than the core system’s text input layer. This is good as it means the core daemon doesn’t need to be run with root, but also means its up to each application to honor input methods. On X11 this is much easier, because all you need to do is have X11 honor the input method, while this doesn’t guarantee every application will still work with it, there are still less moving parts. On Wayland however, the problem gets worse. Wayland expects every application to be in charge of everything itself. Everything from drawing its titlebar and decorations, to honoring input methods. Personally I have been using Wayland for the better half of a year now on GNOME, and I haven’t had as many issues with input methods arising just from Wayland as I thought I’d have, but some applications, particularly ones based on alternate GUI toolkits (not GTK or QT) seem to have the worst problems. With those its just more effective to run them in XWayland and hope that works with the input method.

Although this isn’t to say X11 doesn’t have its own issues with input methods. For some reason, Wayland or not, it seems like GTK and QT universally disrespect the input method. I’m not entirely too sure how the input methods work low level, so I’m not exactly sure how they send their data, but what I do know is multiple environment variables are needed to make sure you get the input method working in applications. Usually this means adding a few lines to your `.bashrc` or what not. Here is my config:

# Can't believe I have to do this in 2019 + ?
export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus

So all of this might be a little alarming, but for the most part, somehow this horrible beast of input methods just seem to work fine. The problem is when technology changes. With the switch from GTK3 to GTK4, I noticed a lot of applications that traditionally worked with input methods no longer work. Whether this is a problem with IBus not supporting GTK4 (despite being integrated directly into GNOME), or GTK4 speaking a different language to the input method, or hell, maybe I need some new undocumented environment variable. This mostly came about when using chromium and other chromium based browsers, which I discovered an override for thankfully.

GTK_IM_MODULE=ibus vivaldi --enable-features=UseOzonePlatform --ozone-platform=wayland --gtk-version=4

Now if that’s all I needed, I would be happy, however of course something has to go wrong. Thanks to flatpak being a sandbox (and flatpak is where I have chromium downloaded), it doesn’t like to play nice with IBus. I’m not too well versed in flatpak, so for all I know, maybe I need to install some module to make it work, but right now EVERY flatpak app cannot work with an input method, like at all.

To be honest, all of this should not be necessary if Linux ever wants to be a household name, especially for people in countries where they don’t use a standard Latin alphabet, or people who speak multiple languages, but want one keyboard. The amount of time I have invested into troubleshooting input methods is insane, and in all honesty, pushes me more towards Windows or MacOS for work in foreign languages, because at least those platforms “Just work :tm:”. This was made worse when during my tenure at a Japanese university, I used only Windows 10, and the experience was so good that all my work in Japanese now is done on Windows.

Hopefully this rant post isn’t too annoying or meandering to find some meaning out of. If you want more information on how to setup an input method, either to torture yourself or otherwise, this arch wiki article provides pretty good information on how to do it. In all honesty, input methods on Linux work. Like period, they work. Its just the sometimes that they don’t, they really stand out more than the many times they do work, especially when on systems like Windows or MacOS, they work constantly. I’m not really too sure how to go about fixing this that isn’t simply “run the daemon at a system level” or “make every Linux application use the same GUI libraries”, all of which the Linux community would hate. So basically, we just have to live with it. いじょうです。