hi, guys I saw this bad news from http://linuxtoy.org/archives/gnome-and-cjk-community-debates-about-ibus-integration-of-gnome-3-6.html
It's a chinese linux news blog, Do you know how to input those characters? I think the input is the most important things of a desktop. If i can't input,no mater how beautiful or powerful the desktop is, it is a rubbish. To the BOSS, If Mr. Linus said the kernel will only support KDE, and KDE will be the standard UI, what will you do? I don't care which one is the default IM, i just care about that i can choose the best one i like. BTW:I like Gnome2 but not 3. i feel Gnome 3 is terrible on my pc. 2012/5/15 Justin Wong <[email protected]> > 独裁无胆，民主无量，打着为民着想的旗号强奸民意，一句资源有限就可以免于全部责任 > > 去吧，发展葛弄姆特色的自由软件 > > Go on your work, hurt more fans and lose more users > > sent from android > On May 15, 2012 7:28 AM, "Owen Taylor" <[email protected]> wrote: > >> In general, choice of input method framework is not a goal in itself. >> If we choose a single input method framework to integrate with GNOME - >> that doesn't make GNOME like proprietary software from Apple and >> Microsoft, >> because GNOME will still be 100% Free Software, and will still be >> developed >> in the open by the GNOME community. >> >> GNOME doesn't want to work well just for tweakers and enthusiasts - it's >> very important to the project that GNOME works well for all users without >> tweaking. We want to give the choice of using Free Software to >> everybody - this is a much more fundamental form of choice than giving a >> small >> group of users the ability to swap out a different input method framework >> underneath GNOME. >> >> GNOME isn't just a set of parts that a Linux distributor takes and uses >> to create a working system - we also take responsibility for creating >> a fully working system. This means deciding how GNOME interacts with >> system components like sound and networking and printing and when >> necessary >> enhancing those components to provide the right experience to the user. >> >> So we can't leave it up to one Linux distributor to combine GNOME with >> fcitx to make a version of GNOME that works well for zh_CN and another >> Linux distributor to combine GNOME with RIME or hime to make a version >> of GNOME that works well for zh_TW. We want GNOME to, without >> customization, >> work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth. >> >> Of course, it would be a mistake to think that a small group of English >> speaking developers could make GNOME work well in all these languages. >> That >> would be impossible! But from experience, we know that simply leaving a >> problem like this to external developers and hoping for the best doesn't >> work out well. Instead we need to engage users and developers from these >> language communities into the GNOME development community. >> >> I don't want to minimize how easy that is - I know there are very >> significant >> barriers of language, timezone, and distance that make this hard. I know >> that bugs get ignored and patches sit around unreviewed. But still, >> active engagement is the only way forward. I think it's absolutely >> wonderful >> how many people have gotten involved in the current discussion! >> >> We also need to keep in mind that we aren't talking about the choice of >> input >> method, we are talking about input method *frameworks*. The basics of >> passing >> events from application to daemon, loading different input method >> backends, >> handling hotkeys and displaying feedback are going to be very similar for >> all East Asian languages. >> >> Things like displaying feedback may be a little different if we move >> further >> afield to Thai or Hindi - but still, there is no fundamental reason that >> they >> need a different *framework*. >> >> Using a single input framework for all GNOME users has many benefits. >> GNOME developers can reproduce bugs that users run into. Bugs only have to >> be fixed once, not in multiple frameworks. We can actually figure out how >> to make input methods work with onscreen keyboards and accessibility. Our >> designers can collaborate on making the configuration dialogs conform to >> GNOME standards. >> >> Finally, using a single input method framework is pretty much essential to >> the goal of allowing users to configure languages at runtime with a nice >> user >> interface. If language A and language B require different input method >> *frameworks*, there is no way that the user can switch between them with a >> hotkey. >> >> In general, I don't see standardizing D-Bus interfaces so that GNOME can >> work with multiple input method frameworks as being a useful activity. >> If the D-Bus interfaces are carefully maintained and changed only with >> agreement and advanced notice, then they will impede the progress of bug >> fixing and making things better. If the interfaces are not carefully >> maintained, then they aren't standards at all, and users will constantly >> encounter breakage. >> >> And in any case, as described above, there has to be *one* framework that >> works as well as we can possibly make it for all users. Multiple partially >> working frameworks are not a substitute. >> >> All of the above is an argument only for picking a single input method >> framework. It doesn't say anything about what input method framework we >> should pick. The fact that the IBus developers have been engaged with >> GNOME for quite some time and are willing to work with us to create a user >> experience that is simple and consistent with the GNOME principles is >> certainly a big plus, but we do need to make sure that the end result >> works well as well as looking good. >> >> - Owen >> >> >> _______________________________________________ >> desktop-devel-list mailing list >> [email protected] >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- 许鹏飞 ( Xu Pengfei ) Beijing China
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
