Re: Does our xim process need an update?

> On Tue, 14 Jul 2015 07:44:10 +0200,
> Qiang Zhao wrote:
>>
>> What an excellent work you have done!
>> And please accept my respect!
>>
>> And I had no intention of offending, but I have some worries to discuss with you:
>> 1, These codes have copyright,
>>      https://github.com/ftake/chameleon-tongue/blob/master/COPYING#L1
>>      I'm not sure if there will be some trouble to merge into OpenSUSE.
>
> Through a quick glance, it looks like a BSD 3-clause license, so it
> should be fine, if it's really so.
>
>> 2, The bin folder have 2 scripts, select-im is written in python, but start-im is written in bash;
>>      Maybe keep consistent is better.
>
> Yes.  Python can be optional on openSUSE, so keeping in bash script
> would be the best, IMO.
>
>> 3, Select the default IM framework base language 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.
>
> 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?
On the other hand,
We still don't know which customer doesn't need more than 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).
Please notice that even we choose by locales, it  will not always be right.

>
> And, last but not least, the case where multiple IM frameworks
> coexit: who decide which IM framework to choose?
>
> (BTW, one interesting thought is to start all IM frameworks at the
>   same time.  This works in theory, and even works practically with Qt
>   that has a IM switcher.  GTK has a fixed binding, so it doesn't work
>   on the fly.  If we have a IM switcher on GTK like Qt, we may start
>   all frameworks no matter whether it's used or not, then let user
>   choose later.)
It is a really good idea, I considered it  in my mind for a long time.
And please notice it brings some new works,
including bug fix, update with SLE, QA... at least.
Many wonderful feature's situation is like that:
Do we have enough people to work on this point in future?

>
>> 4, In /misc/ folder, user use an icon to trigger auto select isn't friendly.
>>      I think we will have a GUI program in future, list all IM framework to allow customer choose 1.
>
> I guess this isn't about icon or menu item to launch by a user
> manually but rather an auto-start desktop file.
Maybe the auto-start work assigned to /etc/X11/xinit is a better choice 
than desktop file.
In this way, IM will start with Xwindow together, but not depend on 
other component to load it.

>
>> 5, In /profile.d/ you gracefully write  fcitx and ibus scripts here.
>>      but We should remember that there may be other IM frame like: scim, xim ...
>>      Also custemer may remove ibus or fcitx manually.
>>      So these start scripts are suppose to keep in the inputmethod rpms,
>>      On the other hand, The select program is independent and installed by default.
>
> Yeah, it's still not designed how to integrate this to each package,
> as it seems.  My understanding is that each package provides the
> profile, just like currently doing to /etc/X11/xim.d/*.
>
> Maybe it's better to provide an RPM macro to set up the things
> properly depending on the target system (xim.d or chameleon-tongue).
> Currently it's open-coded in each spec file.
>
>
> thanks,
>
> Takashi
>
-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]