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 <otay...@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... > 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? - Owen _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list