Re: 3.6 Feature: IBus/XKB integration

[Bastien Nocera <hadess hadess net>]

On Wed, 2012-04-25 at 10:36 -0400, Owen Taylor wrote:
> On Wed, 2012-04-25 at 14:56 +0100, Bastien Nocera wrote:
> > 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.
> 
> I have a hard time seeing how it makes the whole system look antiquated,
> unless you popped up a message containing the bit definitions from
> XKB.h. It's an artificial limitation, and artificial limitations make
> programmers sad, but...

It makes designers sad too, because you need to come up with a good
explanation for the limitations. "Some dude at MIT was trying to save
half an octet" doesn't really cut it.

> > 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.
> 
> Isn't that a whole lot more confusing? Plus, do we have time in the 3.6
> cycle to do a good job at inventing a replacement for non-legacy apps?
> Is that the best use of our resources?

That's an example. And from what I understood, given the "need to
mention the iBus chosen method through envvars" system, I think we have
part of the answer here. We're already effectively working on the
non-legacy replacement.