[Mageia-dev] GNOME plans

[Olav Vitters]

On Mon, Jun 04, 2012 at 08:17:44PM +0800, Kira wrote:
> I got a major concern about the input method in GNOME 3.6+.
> 
> According to some source from the CJK community here and in China,
> 
> GNOME3 would default to iBus  since 3.6+ and very hard to change the
> 
> input method since it's hard-coded. Are we also going to follow this
> 
> direction?

GNOME seems to go to iBus.

If GNOME chooses something, then of course it'll be that way in Mageia,
unless work is done. And I'm not a developer, nor the best maintainer..

I'm involved in upstream, so can change direction.

One thing that's lacking is that nothing is clear about what the needs
are for the input method. The goal is quite simple: it should do what
you want by default. No configuration, changing, etc, just work by
default. Only if something is impossible to automatically figure out,
then add an option. But that's a last resort.

Now, looking from above viewpoint, to make it work by default, it needs
to be very clear what the needs are. But that bit is totally missing. At
the moment the only feedback more or less is that "iBus is not good, has
to be changeable to software YYY and also changeable to software ZZZ".

Such feedback is handy, but not what is needed when talking with
developers/GNOME. What they need to know is what you want out of an
input method. For example: if iBus is not good enough atm, it can be
changed until it is. Extending the functionality of iBus until it meets
everyones needs.

I've seen a lot of feedback on desktop-devel-list at gnome.org regarding
iBus, but the feedback was often focussed on YYY or ZZZ software instead
of describing what functionality is needed. I haven't followed the
latest discussion though.

If you don't like iBus, find the desktop-devel-list at gnome.org thread
(can give pointers if needed), answer the questions that the developers
have about what you think iBus should do (that it currently does not)
and give priorities (e.g. cannot use iBus if it doesn't do X, cumbersome
if doesn't do Y, etc).

-- 
Regards,
Olav