独裁无胆，民主无量，打着为民着想的旗号强奸民意，一句资源有限就可以免于全部责任
去吧，发展葛弄姆特色的自由软件 Go on your work, hurt more fans and lose more users sent from android On May 15, 2012 7:28 AM, "Owen Taylor" <otay...@redhat.com> 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 > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list >
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
