[Mageia-dev] GNOME plans

[Kira]

在 Mon, 04 Jun 2012 22:24:30 +0800, Olav Vitters <olav at vitters.nl>寫道:
> On Mon, Jun 04, 2012 at 09:13:53PM +0800, Kira wrote:
I hope this won't get some misunderstanding between you and me,

since there's some obvious different viewpoint. :)

>> 1. In MCC, we can set up the input method in localedrake, and this
>> setting would be system-wide except GNOME about 3.6+. This should be
>> mentioned, because it would destroy the unified user experience.
>
> As said, I don't code. And unified experience I care for GNOME, that it
> works consistently. I care about freedesktop.org standards. I don't care
> for differences between distributions. E.g. MCC is great, but I prefer
> if it didn't exist. MCC is only Mageia/Mandriva, another distro has
> other things, etc.
> I prefer something in gnome-control-center.
>
Well, I think this should be proposed to more upper level...

Because this affect the Mageia distribution, though.

I believe Mageia still keeps the faith to achieve better unified

user experience than other distribution.

>> 2. For users who want other input method, is there a easy way to do it?
>> I must remind here: I think most developer in GNOME don't really know  
>> the
>> pain for our CJK user here. Whether iBus or other input method all
>> don't meet the completeness that most people need. iBus continuously
>> lost the word typed, Hime/GCIN, and others more don't have easy way to
>> add up other input module, and scim/oxim... and more are even out of
>> maintenance.
>
> iBus losing words sounds like something fixable.  Fairly strange that it
> does that though.
>
> And that most developers don't know much about CJK, agreed. That's why
> it is important to figure it out. I even have less of a grasp, as not a
> coder/developer.
>
Here I just want to point out the problem of each input method existed...


>> The main point of issue is that we hope to have the freedom and have
>> the input method that fit each other's need( There's at least 10+
>> input modules exist), and the way GNOME implement the unified input
>> method had very bad impression for us.
>
> GNOME is not about being able to change loads of things since
> development of 2.0 began. You say you need the freedom to ensure the
> input method does what you want.
>
> So why not ensure the default input method does what you want?
>
> I get the impression that each time a new input method is abandoned,
> some new project is started, gets abandoned again, etc. Resulting in a
> wish for the ability to always being able to change the input method.
>
So that's the problem of hard code iBus as the main player. SCIM had been

once the major input method in major distribution, but ever since it's

out of maintenance, iBus kicks in and gradually take the major for  
"global".

But that's not the case here in Taiwan or in China. We got about 50-50 in

Hime/GCIN vs iBus as far as I know, and most people would like fcitx in  
China.

Sure you could force people to use iBus instead, but that really bad  
impression

and does no good to others since Hime/GCIN/fcitx works great and many  
efforts are

put into them, and these effort can't be transplant to iBus since they  
works differently.

The problem of selecting single input method is that: what if, iBus dies,

then GNOME would have to rewrite the whole structure, or GNOME would jump

in and make sure it won't die? Isn't it better to do it like KDE or other  
DE

to have the possibility of choosing?

>> You guys do a good job, but the decision of easily bundle up a single
>> input method is really a bad idea, because not all people want to
>> contribute to iBus project, and they already have effort on other
>> input methods.
>
> Of course there are developers involved in other input methods. But
> not doing something because they might get offended.. this is not really
> how a decision would be taken. Focus is on what gives a nice experience.
>
>
Well, I think the point is this decision won't brought nice experience to  
CJK users, or even more.

I know you are not the decision maker, but I hope, at least here,

we could find a way to do better, not just follow the upstream.