Hi Owen, I heartily agree with this a statement of direction to pursue; standardization is a good principle.
But there is the matter of the timetable for rolling this out -- considering the feedback from CJK users, I think assessment is needed of what work should be done on the chosen framework *itself* before a sound decision on whether the standardization should happen in the 3.6 cycle can be made. Tomas On 15/05/12 00:27, Owen Taylor 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
