Re: Some points about IM integration

[Tomas Frydrych <tf+lists gnome r-finger com>]

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
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list