GNOME and input method integration [LWN.net]

GNOME and input method integration

Posted Jun 27, 2012 11:15 UTC (Wed) by emk (guest, #1128)
Parent article: GNOME and input method integration

How many [DELETED BY AUTHOR] times is Gnome going to break my workflow, anyway? I know they want an out-of-the-box experience that Just Works, and I applaud them for that. But in practice, that means that my desktop breaks horribly every year or two, because I'm always running beta-quality software that never has decent drivers or integration.

I rely on UIM and UIM-el to enter a bunch of Unicode characters, including the International Phonetic Alphabet (ɑɦɔ), Egyptian hieroglyphics (𓀀𓁐) and hieroglyphic transliterations (ꜣı͗ˤ). This works correctly in Gnome, in Chrome and in Emacs, plus Java applications and X11. Granted, it took a day of kicking to make everything work, which is definitely not acceptable. But it works.

Of course, none of these character sets are supported by ibus, and the relevant API documentation appears to be in Mandarin.

In order to get a nice user experience, we're now going to standardize on a new input framework. Of course everybody who actually uses Chinese or whatever thinks it's horribly broken. The Gnome folks respond, "Ah, but now that we've made an official choice, you can fix it and make it work. No, we're certainly not going to provide a fallback or work around other people's bugs—Gnome won't work until everything else is fixed; that's the only way to make progress."

And the Gnome team is right—after two or three years of horrible breakage for everybody affected, IBus will finally support the basics: online word lookup, customizable dictionaries, Traditional Chinese, obscure languages, and so on. At which point, they'll standardize on some other incomplete, broken technology—probably Wayland. And we'll go through this all over again.

Gnome, sadly, is all about a positive experience for hypothetical future users. But in the real world, all the non-technical Gnome users I know live in mortal terror of the next upgrade, because it's either going to break their laptop beyond repair, or force them to completely relearn the UI.

I don't know how to solve this. I want a nice UI, too, and that involves hard choices. But I kind of wish we could have a world-class input method first, and then integrate into Gnome, instead of planning on a couple years of nasty, user-visible breakage while third-parties scramble to fix everything.

(Log in to post comments)

GNOME and input method integration

Posted Jun 27, 2012 12:38 UTC (Wed) by marcH (subscriber, #57642) [Link]

> XXX, sadly, is all about a positive experience for hypothetical future users. But in the real world, all the non-technical XXXX users I know live in mortal terror of the next upgrade, because it's either going to break their laptop beyond repair, or force them to completely relearn YYYY.

Yet another summary of the Linux Desktop experience!

> I don't know how to solve this.

Commercial software is reasonably good at solving this problem (and less at others). It works like this: paying customers threaten to slay a few salesmen in case of any regression. Scared salesmen threaten to slay developers in case of any regression. Managers staff validation teams to keep everything under some level of control.

This obviously does not work when developers are left alone/in charge. When developers are in charge you get a grand revolutionary design every year or two. Which never gets completed before the next one.

Sorry this is getting a bit off-topic.

GNOME and input method integration

Posted Jun 27, 2012 14:00 UTC (Wed) by emk (guest, #1128) [Link]

OK, I just took a look at iBus, and here's what I've found. Note that I'm running Ubuntu 11.04, because that's what shipped on my laptop last November and I haven't upgraded yet. Why haven't I upgraded? The usual reasons:

I wasn't crazy enough to try the first version of Unity.
Now that Unity is semi-mature, I've been too busy with paying projects to risk massive breakage.
I have no idea how much of my laptop's hardware will stop working if I upgrade, even though I paid extra for a high-quality Ubuntu preload from an award-winning vendor.

So, how about iBus?

The UI actually looks halfway decent. I could like this.
The keystrokes used for controlling pre-edit are completely different from what I expect. A sequence like "c," automatically commits the "c" instead of waiting for "ç". It looks like I need to type "c1" to get "ç", which is just ridiculous, and would make phonetic input of hieroglyphs unbearable. There's presumably something I'm missing here.
It looks like I get IPA, hieroglyphics, etc., working by generating big plain-text tables, which isn't too awful. But then again, these are easy scripts.
It's completely broken for Java apps. I have no KDE or X11 apps lying around, so I can't test those. There's a ibus-kde plugin which hasn't had any commits in two years.
It breaks Emacs hard, including the XCompose sequences that I use to type French—even if I override the relevant environment variables to tell it to leave Emacs alone. Presumably I can load ibus-mode to integrate with Emacs, but I doubt that's going to fix XCompose. Oh happy joy.

Pretty much par for the course, really. Shiny but broken, and Gnome will ship it long before it's actually in a semi-usable state. And I have no idea what will happen with non-Gnome apps.

And this will be an especially bad transition, because users can't actually complain without fighting through an enormous language barrier. Reading through the threads that our editor linked, I see Chinese users and developers pouring their heart out in badly-broken English. Then the Gnome developers like Owen Taylor just steamroller them with beautiful, eloquent native prose. I've been on the other side of that particular dynamic, and it's no fun at all.

GNOME and input method integration

Posted Jun 28, 2012 3:27 UTC (Thu) by csslayer (subscriber, #85354) [Link]

You need ibus-xkb for such case.

GNOME and input method integration

Posted Jun 27, 2012 13:58 UTC (Wed) by zlynx (subscriber, #2285) [Link]

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.

GNOME and input method integration

Posted Jul 3, 2012 12:25 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> like hardware support for this year's laptops, they will have to switch to using Gentoo Linux or more likely Mac OS X.

Mac OS X only has hardware support for a few laptop models.

GNOME and input method integration

Posted Jul 3, 2012 16:35 UTC (Tue) by zlynx (subscriber, #2285) [Link]

And on those laptop models OS X works perfectly.

I do know that when I upgraded to a Macbook Pro in 2008 it was a great relief and very refreshing to know that every time I closed the lid it went to sleep. Every time I opened the lid it woke up.

It didn't stay awake and burn away the battery because Gnome had decided to create their own power management daemon and do it very badly. (Oooh, there's a sysfs file that is missing/in the wrong place/has different contents or permissions! I had better crash and not restart!)

It didn't kernel panic on resume.

Playing sound worked in every application, every time, without needing to search for whatever app had locked the sound device.

Linux cannot claim these things. It is certainly a more interesting OS, but it does cause a strain.

GNOME and input method integration

Posted Jun 27, 2012 14:34 UTC (Wed) by emk (guest, #1128) [Link]

> 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.

GNOME and input method integration

Posted Jul 7, 2012 4:35 UTC (Sat) by rodgerd (guest, #58896) [Link]

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.

GNOME and input method integration

Posted Jul 7, 2012 15:13 UTC (Sat) by tuna (guest, #44480) [Link]

IBus for mainland standard Chinese and Japanese work pretty well. For Cantonese and other Chinese input method types it might not be as good as other input frameworks.

The upside if Gnome would add Ibus for 3.6 is that you would not have to add and configure a lot of extra software in order to input CJK.

In Fedora 17, there is one keyboard configuration tool and one Ibus configuration tool. It is way easier just to have one.