GNOME and input method integration

But they probably will break things that aren't broken.

There are people who have managed, however they had to do it, to get input systems working in current versions of Gnome.

Everyone suspects because of past history with these things, that these new improved versions of Gnome will break all the currently working things. And, these new "improved" versions of Gnome will have no way to turn off the new things because the Gnome developers want to force everyone else to fix the problems rather than revert to what already works.

The distros don't help with this because they make it nearly impossible to run older versions of desktop software. For example, if you want to use a new version of Ubuntu, all of the packaged software will be linked to the newest possible version of Gnome. The same with Fedora.

For many people then, to keep using software that works and still get at least some modern features, like hardware support for this year's laptops, they will have to switch to using Gentoo Linux or more likely Mac OS X.

So in the quest to make things "better" Gnome developers often end up making it impossible to get work done and drive people to proprietary software.

> Isn't the whole point of this article that there is no world-class input method system that just works for everyone? In this case the Gnome devs aren't breaking anything that isn't already broken.

I don't have good answers here. I want a nice, standard input method that Just Works, too. I'm happy if that's ultimately iBus, at least if I can convince it to handle phonetic input with manual commits, preferably without writing a lot of C code.

What we have now are a number of clunky-but-mature solutions that cover a lot of use-cases: Traditional Chinese (for Taiwan), phonetic customizations (for Chinese "dialects"), online dictionary lookup, enterprise users who run Java apps, Emacs users who need both XCompose *and* an input method, and so on. Chinese speakers probably get all this from their distro, whereas users with specialized needs probably spent a day reading tutorials and kicking stuff.

As far as I can tell, iBus is well-designed but relatively immature, and it's of limited utility outside of Gnome.

I can see some sensible ways forward: We could announce that iBus is the future, make it an overridable default in most distributions, and spend a year or two ironing out the bugs. Or we could just go ahead and make iBus mandatory in the next release, while it's still half-baked.

I really want a beautiful, well-designed UI, and I'm willing to sacrifice a lot of customization to get one. But I'm not willing to put up with massive regressions every 6 months.

You must have read a different article to the one I did; in the one I read, there is one option which has some shortcomings but is widely used by people who speak, read, and write CJK languages as the best option, and some other option considered vastly inferior for people who use the languages in question.

The GNOME developers, who don't for the most part have no first-hand expernience of the problem space, following their usual user-hostile model of development, ignored what their users told them and went with the less useful option on the grounds there will be jam tomorrow.