Re: 3.6 Feature: IBus/XKB integration
- From: Marguerite Su <i marguerite su>
- To: "Jasper St. Pierre" <jstpierre mecheye net>
- Cc: Owen Taylor <otaylor redhat com>, desktop-devel-list gnome org
- Subject: Re: 3.6 Feature: IBus/XKB integration
- Date: Sun, 13 May 2012 01:18:52 +0800
On Sat, May 12, 2012 at 11:58 PM, Jasper St. Pierre
<jstpierre mecheye net> wrote:
> We only have the development resources to ship one input method. It's
> going to need special code to integrate with Clutter and the St
> toolkit. If IBus is bad right now, we need to fix it.
>
> On Sat, May 12, 2012 at 12:55 PM, Marguerite Su <i marguerite su> wrote:
>> On Sat, May 12, 2012 at 10:51 PM, Owen Taylor <otaylor redhat com> wrote:
>>> Hi Maguerite,
>>>
>>> Thanks for the detailed response!
>>>
>>> It's hard for me to talk about the pros and cons of fcitx and IBus -
>>> sadly I don't speak or write Chinese, and I haven't investigated the
>>> technical operations of these systems either.
>>>
>>> But what I do want to talk about is the user experience we try to create
>>> in GNOME. In general, our goal isn't maximum choice. It's the best
>>> possible experience.
>>>
>>
>> yes, I can understand your goal. to be honest, users are fool,
>> although I'm one of them.
>>
>> maybe in coders' eyes. I can't code, I can't understand the tech or
>> code details.
>>
>> I'm just a packager. I come to post here because I heard IBus may be
>> compulsory for GNOME. like if you install GNOME, you have to install
>> IBus. and if you want to uninstall IBus, you have to uninstall the
>> whole GNOME.
>>
>> that's what I'm worried. I don't want to see this sad thing happen.
>> because GNOME is still awesome. so no one is preventing you developing
>> IBus integration. but please make sure I at least can build and run
>> GNOME without IBus. or create an universal solution that can benefit
>> every nowadays and future input methods.
>>
>> actually, fcitx, here, can be any other input method. because users
>> are really tired of IBus, endure enough of its bugs(not GNOME bugs,
>> but IBus ones). they don't even want to hear its name. Once users have
>> bad impression on it, it's harder to call him back than newcomers. so
>> at least we have to give them some time to re-accept IBus if you
>> really vote for IBus.
>>
>> if not, then I'm exiting because you are making the world a better place.
>>
>>> A user starts using GNOME. They have trouble inputting Chinese text.
>>> A friend sees their computer, tells them to uninstall IBus and install
>>> fcitx. Things work much better. Is this a success of Free Software?
>>> No - it's a failure. We gave the user an operating system that didn't
>>> work until someone fixed it.
>>>
>>
>> No. it's not a failure of FOSS, nor GNOME.
>>
>> it's a failure of IBus.
>>
>> the solution is to drop IBus. and provide an universal solution for
>> competitors to join.
>>
>> not take the bad one into your own hands.
>>
>> that's nature selection.
>>
>> let IM developers do their own homework. we're focusing on our GNOME.
>>
>> like you said, a developer who actually use his product is the best developer.
>>
>> even GNOME developer make it work for now, it will certainly fail
>> another day. because most of the GNOME developers don't even use an
>> IM.
>>
>>> In my experience, there is almost no chance most users will understand
>>> the concept of an input method framework. Users are busy talking to
>>> their friends, doing school work, or inventing the cure for cancer. They
>>> don't want to take a course in how their computer works internally. We
>>> can provide options behavior - are they using Pinyin or the Four-Corners
>>> method? But we shouldn't give them options for how applications talk to
>>> the input method.
>>>
>>
>> True.
>>
>>> We also really value using the same basic components on all GNOME
>>> systems. You hit a crash on your system in GNOME Shell when using
>>> fcitx, and you report it in GNOME bugzilla. If I'm using fcitx, then
>>> I can reproduce the bug and fix it. If I'm using IBus or no input method
>>> framework, then the bug may never be fixed.
>>>
>>
>> why can't you mark it upstream and send it to fcitx/IBus developers?
>>
>> that's my standard workflow.
>>
>> I'm not its developer, I can't fix it better than its developer.
>>
>> so I won't get my hands full and dirty.
>>
>> just let experts do their work. I'll do mine. life will be pretty much easier.
>>
>>> Users should also be easily able to mix and match and switch between
>>> languages. This means that we need an input method framework that works
>>> well for all the input methods - we can't have one input method
>>> framework for Chinese, and another for the languages of India.
>>>
>>
>> Why can't?
>>
>> Actually no IM developer can develop an IM perfect on all languages.
>>
>> he just provides universal framework for other local developers to
>> join. and focus on his part.
>>
>> if someone is better than him in some area, users will certainly go there.
>>
>> so why we prevent users from making their own choices?
>>
>>> So, please make the argument that fcitx is better and more aligned with
>>> the philosophy of GNOME and should be used instead of IBus!
>>>
>>
>> I'm not talking about "instead of", it's not a war than one side
>> eliminates the other.
>>
>> it's to let them "live together".
>>
>> and why I came here because I thought GNOME is eliminating all other IMs.
>>
>> so I think it might makes me feel better if anyone come on explains to me that
>>
>> GNOME is not eliminating anyone.
>>
>> as I said, it's not a war. you don't have to manually pick any winner.
>>
>>> The best way to make that argument is to explain it to us -
>>>
>>> * Does fcitx allow for an easier-to-understand configuration user
>>> interface? Do you have screenshots?
>>>
>>> * Does fcitx have better feedback to the user while they are entering
>>> input?
>>>
>>> * Does fcitx have better dictionaries and algorithms in its input
>>> methods?
>>>
>>> * Is fcitx less buggy?
>>>
>>
>> I'm a user, that's not my question. all I can provide is what end
>> users actually want.
>>
>> I'll provide the final result of my survey. that's all I can help you.
>>
>> Comparing tech and low-level parts of two IMs is not an end user's
>> work, and it's rude to ask such questions to an end user.
>>
>> and what I want to mention is,
>>
>> we all know junk food is bad to our health. but many people like it.
>>
>> so it still sell well.
>>
>> we can vote for better life style. but can't eliminate junk food all
>> in a sudden.
>>
>> so even if fcitx or any other IM is junk food, you can choose to not eat it.
>>
>> but you can't eliminate the possibility that others to eat.
>>
>> not to say, fcitx is the nowadays user choice.
>>
>>
>>> - Owen
>>>
>>>
>>
>> Marguerite
>> _______________________________________________
>> desktop-devel-list mailing list
>> desktop-devel-list gnome org
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
> --
> Jasper
1. it's not your responsibility to "ship" any input method. you don't
even have a repository facing end users!
it's not like kernel, it's users' choice. if you push the users. users
will leave you.
2. it's not your responsibility to "fix" ibus bugs. unless you're an
IBus developer.
3. about the "development resource" thing.
IBus today is not so bad integration with GNOME. so no need to
integrate it any tighter. just fix the bad and broken part if you do
want to.
and if you integrate it. it's even worse than now.
like I said, users can't change input methods then. (if wrong, fix me)
and most of you do not use IM.
and CJK users seldomly report bugs to upstream, because their english
is not good enough to. (that's any important background knowledge,
many of them don't even know what a bugzilla is, they can't even
pronounce the word right)
then the situation will be:
IBus has bugs.
You don't know.
Users endure it and can't change it or drop it.
at least today, users can switch.
hope it helps
Marguerite
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]