Re: Does our xim process need an update?

On Sun, 02 Aug 2015 10:43:18 +0200,
Qiang Zhao wrote:
> 
> 
> 
> 在 2015年07月29日 14:35, Takashi Iwai 写道:
> 
> >>>> 2, Create a selection table on GDM. it will call chameleon tongue's
> >>>> desktop file later when customer successfully login.
> >>>
> >>> This would give a flexibility, indeed, but OTOH, too many knobs are
> >>> messy on login screen from UI/UX POV.  I guess GNOME devs won't like
> >>> yet more button in the standard login screen.  But, moving it into a
> >>> special dialog won't help much, either; switching to a different IMF
> >>> is mostly only for experts, and such people can likely do it in other
> >>> way.
> >> Yes,  It's a kind of solution, not the best.
> >> But  In my mind, Let customer select is better than auto select.
> >> Because auto select not always right for customer.
> >
> > But if they doesn't care?  Asking too much is rather harmful for
> > them.  And I bet majority of users don't care about the difference of
> > IMF, as long as it works.  So, this comes to the question of justice:
> > whether to serve for majority or to save minority.  There can be never
> > 100% "correct" answer here.
> >
> I have reread your e-mail:
> If users don't care the difference of IMS,  they will also don't care be 
> assigned an pre defined IMF too, in this way,  we don't need auto select.
> I want clear that  the "auto select" we discuss here means select an IMF 
> base user's LANG env.

Maybe this definition of "auto select" misleads the discussion.
In general, "auto select" is the way to select the default IMF without
user's explicit interaction.  Thus, the auto select is more or less
mandatory for normal systems with multiple choices.

If your suggestion is only about locale-specific auto select, then it
might be worth to discuss.  The question is what would the advantage
of dropping per-locale selection be.  Is it a reduction of maintenance
cost?  Well, I don't think it has been so big burden, so far.  It's
rather a once-off thing.  A reduction of code complexity?  This might
be a good argument, especially if a new framework is developed.  OTOH,
Takeyama-san already implemented this, so is it worth to modify / drop
again?

Meanwhile, looking at the development history, you can find a
different POV to this.  The per-locale auto select made it possible to
choose an IMF depending on the support status.  For example, fcitx was
chosen as a default IMF for Chinese because it has been more widely
tested in that locale although it was new.  For other locales, ibus
was kept as default because it has been longer used.  The per-locale
selection has some practical merits (more flexibility) in that regard.

So far, all what I wanted to say is that we need serious evaluations 
of such merits and demerits in order to judge whether to drop a
feature.  If you have another good argument, we'd happily listen to
it, of course.  Let's enjoy discussions!


> For SLE:
> Because of we only keep only 1 IMF installed by default in the feature 
> we metioned,
> So run auto select at first time login is not useful.   if user install 
> another IMF from source, he will make  a switch to new IMF or not only 
> by their own favor.
>
> For your previous idea:
> We don't need to modify SLE installation program, because only 1IMF 
> install by default, so user don't need to select.
> I think  Add a dialog in "Settings" -> "region &language" is fine,  user 
> can install other IMF and switch if they need;

Right.  One nice feature I'd hope is the inquiry and installation of
IMF packages in this YaST module.  We may provide some tags in each
package to advertise itself, so that user can query and list up
packages via zypper.


> For OpenSUSE, hope can insist on your previous decision, because it's 
> far more better than current.
> But if you install 2 or more IMF in system installation, Maybe you still 
> need modify installation program.

Yes, some tuning would be needed in anyway for the migration.  And, we
must not underestimate this: the migration is one of the most
important functions in the distribution after all...


thanks,

Takashi
-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]