Re: Does our xim process need an update?

 >
 > One alternative I've had in my mind is the explicit selection of IMF
 > at installation time in YaST.  It essentially means to always set a
 > value in /etc/sysconfig/language.  Most of desktops are on PC for a
 > dedicated person, thus a system-wide setup is equivalent with the
 > user's setup.
 >
 > It has a few merits: GUI can be easily provided via YaST.  And, by
 > allowing the selection at installation, we can avoid installing
 > unnecessary packages (other IMFs).
 >
 > Actually, this idea existed since the beginning of IMF setup via
 > xim.d/*.  When Mike an I discussed about the implementation (many many
 > years back), YaST IMF selection was the first candidate.  But this
 > needs the work in YaST, and we didn't want annoy YaST developers,
 > hence the priority list was introduced as a self-contained
 > implementation.
 >
 > Maybe it's time to bring this idea back.  This scenario isn't perfect
 > yet, though: e.g. it doesn't cover how to migrate -- if the old system
 > has no IMF selection, how should we do after upgrade?
 >
 >
 > Takashi

I support this solution.  And I think it will help a lot.
And lots of other distribution also act as the same method, only have 
different in details.
But I think your design should show us more details?

For others of your feedback, I will not have much objection on them.

> On Wed, 29 Jul 2015 06:01:15 +0200,
> Qiang Zhao wrote:
>>
>>> On Mon, 27 Jul 2015 15:12:15 +0200,
>>> Qiang Zhao wrote:
>>>>
>>>>
>>>>
>>>> 在 2015年07月26日 15:37, Fuminobu TAKEYAMA 写道:
>>>>> I've understood your opinion.
>>>>>
>>>>> We have started to discuss technical problems to realize our idea
>>>>> including your "manually selecting IM name".
>>>>>
>>>>>
>>>>>    > On this point, the default settings should be "auto select depending
>>>>>    > on the current locale"
>>>>>
>>>>> This means that we still need "auto select" to allow users to use
>>>>> some IMs before selecting IM and restarting at the first login.
>>>>>
>>>>> If it is acceptable that users need to restart at the first login to use
>>>>> IMs, I think "auto select" is not necessary.
>>>>>
>>>>> # Of course, we must provide a mechanism to ask which IM the user wants
>>>>> to use.
>>>>>
>>>>> Fuminobu Takeyama
>>>>
>>>> I want to say:
>>>> 1, allow users to use some IMs before selecting IM at the first login is
>>>> useful.
>>>
>>> Yes... and a bit of No.  See below.
>>>
>>>> 2, The "auto select" is not necessary;
>>>
>>> Hmm, what if the system has two IMFs installed?  Which one to take?
>> I hope we can let customer to choose by themselves (modify
>> gnome-initial-tools or modify gdm or others).
>>
>>>> 3,  We must provide a mechanism to ask which IM the user wants.
>>>>
>>>> I think there are 2 ways to ask our costomer:
>>>> 1, gnome-initial-setup ( l don't get the reason why we deprecate, I
>>>> don't find the reason in ML or any other docs.)
>>>
>>> I don't think we won't go for deprecating gnome-initial-setup.  But,
>>> eventually we might need to work around the conflict with it. The
>>> problems are:
>>>
>>> - gnome-initial-setup isn't included in SLED12 (it was disabled
>>>     explicitly).
>>>
>>> - It doesn't consider for other IMFs than ibus.
>>>
>>> I'm not 100% sure about the latter.  Hopefully this got improved
>>> recently.
>>>
>>> And, gnome-initial-setup solves only for GNOME.  So...
>> but can modify gnome-initial-setup.
>> I think the major obstacle is the work load.
>> What I want to say is, let customer to select at this point is correct.
>
> Sure, it'd be helpful in some scenarios, as I already agreed.
> (But "correct" isn't a right word, as there is no 100% correctness;
>   see below.)
>
> The biggest problem of your proposal is the maintenance cost, indeed.
> We'll need to cover not only GNOME but other DEs (KDE, XFCE, LXDE,
> E17, bare X with many WMs).  You can guess easily that supporting all
> these is far heavier than the current way.  The auto-select is
> self-contained in IMF packages, and no other changes needed.
>
>
>>>> Or create another program to take the position.
>>>
>>> ... something is still needed for other DEs (including the primitive
>>> one like icewm or bare X).  Oh, also we need to think of Wayland... in
>>> some time future.
>>>
>>>> 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.
>
>
>>> Also, we shouldn't forget about the presence of system administrator.
>>> A sys admin may set up the default IMF in /etc/sysconfig/language.  In
>>> that case, sys admin doesn't want to let user choose IMF explicitly
>>> but rather leave the default as much as possible.
>> But please note that "auto select" is another kind of "user choose IMF
>> explicitly".
>>
>> for clarify some facts:
>> current situation:
>> 1, /etc/sysconfig/language
>> 2, auto select | customer select
>>
>> and what I hope:
>> 1, /etc/sysconfig/language
>> 2, customer select
>
> OK, this gets clearer.
>
>
> One alternative I've had in my mind is the explicit selection of IMF
> at installation time in YaST.  It essentially means to always set a
> value in /etc/sysconfig/language.  Most of desktops are on PC for a
> dedicated person, thus a system-wide setup is equivalent with the
> user's setup.
>
> It has a few merits: GUI can be easily provided via YaST.  And, by
> allowing the selection at installation, we can avoid installing
> unnecessary packages (other IMFs).
>
> Actually, this idea existed since the beginning of IMF setup via
> xim.d/*.  When Mike an I discussed about the implementation (many many
> years back), YaST IMF selection was the first candidate.  But this
> needs the work in YaST, and we didn't want annoy YaST developers,
> hence the priority list was introduced as a self-contained
> implementation.
>
> Maybe it's time to bring this idea back.  This scenario isn't perfect
> yet, though: e.g. it doesn't cover how to migrate -- if the old system
> has no IMF selection, how should we do after upgrade?
>
>
> Takashi
>
>
>>> Last but not least, we need to think of the shared NFS home.  On such
>>> a system, the selected IMF isn't always available on each machine.
>>> So, a fallback ("auto select") would be required.
>> I think "/etc/sysconfig/language" is his fallback.
>> And we do not need 2 layers of fallback right?
>>
>>> Takashi
>>>
>>>> Qiang Zhao
>>>>
>>>>    > to use.
>>>>>
>>>>> On 2015年07月23日 20:40, Qiang Zhao wrote:
>>>>>>    > On this point, the default settings should be "auto select
>>>>>> depending on
>>>>>>    > the current locale"
>>>>>>    > so far.
>>>>>>
>>>>>> Sorry, I  think I didn't express my thought very clearly,  See the
>>>>>> previous discussion:
>>>>>>
>>>>>> Qiang:
>>>>>>    > 3, Select the default IM framework base language(current locale) is
>>>>>> useless in my opinion,
>>>>>>    >      So I think select-im only accept an IM name parameter, and set
>>>>>> for current user is enough.
>>>>>>    >      also, no need to divide in locale.d sub-folders. See my previous
>>>>>> email.
>>>>>>
>>>>>> Takashi
>>>>>>    > For IM "frameworks", it makes little sense to limit per locale,
>>>>>>    > indeed.  Most of IM frameworks are locale-agnostic.  Rather their
>>>>>>    > input method (engine) is specific to locale.  e.g. only ibus or fcitx
>>>>>>    > package is installed without the engine like ibus-mozc, it's almost
>>>>>>    > useless.
>>>>>>    >
>>>>>>    > A related question is whether we should mandate the IM framework for
>>>>>>    > all locales.  If user doesn't need more than XKB, why another layer
>>>>>>    > should be there to make things complicated?
>>>>>>
>>>>>> Qiang:
>>>>>>    > On the other hand,
>>>>>> -  We still don't know which customer doesn't need more than XKB.
>>>>>> + We still don't know which customer only need XKB.
>>>>>>    > So I think the better solution is to make an option on
>>>>>>    > chameleon-tongue/profile.d
>>>>>>    > of XKB(No IM Frame work but only XKB).
>>>>>> + At the same time, abandon "auto select depending on  the current
>>>>>> locale"
>>>>>>    > Please notice that even we choose by locales, it  will not always be
>>>>>> right.
>>>>>>
>>>>>> Takashi:
>>>>>>    > Right.  Currently "none" corresponds to XKB, as XKB is always there as
>>>>>>    > default on X.
>>>>>>
>>>>>>
>>>> --
>>>> To unsubscribe, e-mail: [email protected]
>>>> To contact the owner, e-mail: [email protected]
>>>>
>>>
>>
>
-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]