Re: 3.6 Feature: IBus/XKB integration

[Bastien Nocera <hadess hadess net>]

On Wed, 2012-04-25 at 09:37 -0400, Owen Taylor wrote:
> On Wed, 2012-04-25 at 11:10 +0100, Bastien Nocera wrote:
> > On Wed, 2012-04-25 at 09:34 +0200, Rui Tiago Cação Matos wrote:
> > > On 24/04/2012, Owen Taylor <otaylor redhat com> wrote:
> > <snip>
> > > > So, I don't think it really works to just ignore the group mechanism of
> > > > XKB and always load a one-group layout... it makes more sense to me to
> > > > identify what layouts are needed for all the input sources and load them
> > > > into a single keymap ahead of time. Yes, that might limit the user to
> > > > switching between 4 languages, but, really, how common is it to need
> > > > more than that?
> > > 
> > > Ok, that sounds like the best way forward then. And yes, I agree that
> > > users don't need to switch among more than 4 languages.
> > 
> > The 4 layouts limit is an artificial limit that causes bug reports and
> > raised eyebrows, and was one of the bugs that the ibus/xkb integration
> > was supposed to fix. Missing out on it would be a great
> > disappointment...
> 
> But the main point of the exercise is to provide an integrated, well
> designed user interface for inputting languages with billions of users
> in total. Are people really reporting bugs because they need more than
> 4 layouts, or because the UI acts confusing when you try to add more
> than 4 layouts?

It makes the UI confusing, and makes the whole system look antiquated.
That means that the new system needs to work with the existing legacy
system to remove those limitations, rather than provide a thin layer on
top of the existing limitations.

I don't see a problem adding a "only the first 4 layouts are available
to legacy applications" message or something of that ilk.

> I'm sure we can engineer a solution to enable more than 4 layouts if
> that's really a requirement ... if nothing else, revise the XKB
> protocol. But let's not confuse that with the actual goal here.