Re: Does our xim process need an update?

在 2015年07月15日 22:38, Fuminobu TAKEYAMA 写道:
>  > One relevant question about the system setup: should we fix to an IM
>  > once when started/used, or keep it dynamically evaluated at every
>  > start?
>
> I supposed that chameleon-tongue will show a dialogue or notification
> if it detects a new IM.
>
> If users have selected a specific IM before the change and ignore the
> notification, it does not change their setting.
>
>
>  > Do you mean that it will help for users to choose the primary IMF at
>  > installation?  I don't get exactly in which situation you supposed.
>
> No. It is just a naive feature that allows users to install packages
> of IMs from an IM-setting dialog provided by chameleon-tongue.
>
> On 2015年07月15日 01:31, Takashi Iwai wrote:
>> On Tue, 14 Jul 2015 18:01:48 +0200,
>> Fuminobu TAKEYAMA wrote:
>>>
>>> Hi,
>>>
>>>> - Migration from old /etc/X11/xim setup;
>>>>    we need to keep the setup as much as possible.  How can it be done
>>>>    gracefully?
>>>
>>> Honestly, no good idea.
>>> But I know many users use automatic selection of IMF or have only one
>>> IMF on their system.
>>
>> Right, it's my guess, too.  That said, we'd need at most to evaluate
>> /etc/sysconfig/language:INPUT_METHOD value, but forget about the setup
>> in ~/.profile.  Who managed to set up ~/.profile should be able to
>> follow such an easy technical change :)
>>
>>> The new script have a chance to be more interactive, which means
>>> it can show its dialog or message to set up IMs after some system
>>> changes.
>>> So they should be able to switch to the new launcher and set up IMs
>>> smoothly.
>>
>> One relevant question about the system setup: should we fix to an IM
>> once when started/used, or keep it dynamically evaluated at every
>> start?
>>
>> This question is something like the current window manager selection.
>> In the former case, we record it at the login.  Then, even if a new IM
>> package is installed later, the same previous IM will be used, no
>> matter how the default priority is set.  The latter case is like the
>> current implementation, we take whatever the system default regardless
>> of the previous usage.
>>
>>
>>>> - Let's add a description file to each profile directory, e.g. create
>>>>    a file /usr/lib/input-method/profile.d/XXX/description, so that a
>>>>    program that selects IM can show the content of each entry more
>>>>    nicely.
>>>
>>> Sounds good!
>>>
>>>
>>>> - Is the start of daemon solely done by the desktop file?
>>>>    What if a bare DE that doesn't start desktop files?
>>>
>>> It should have a black list of DEs that do not support desktop files.
>>> If the current session is one of them, the script in
>>> /etc/X11/xinput.rc.d/
>>> can start an IMF in the same way as the current script.
>>
>> OK, that's also my expectation.
>>
>>
>>>> - The ugly g-s-d workaround: can we implement this in a bit smarter
>>>>    way once when we redesign the framework?
>>>
>>> The workaround does not work as expected anymore on 13.2.
>>> (Let's discuss in a new thread)
>>>
>>> An idea is to ask users if they use IBus (only on GNOME) or not.
>>
>> OK.
>>
>>>> - It would be safer if we can avoid python for select-im...
>>>
>>>>> 2, The bin floder have 2 scripts, select-im is written in python,
>>>> Yes.  Python can be optional on openSUSE, so keeping in bash script
>>>> would be the best, IMO.
>>>
>>> It is just the first prototype.
>>> I've already rewritten it into a native application.
>>>
>>> Then, I want to avoid a complex shell script, which is one of my
>>> motivation.
>>
>> Yeah, it's just an implementation detail we can tackle later.
>>
>>>> 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.
>>>
>>> That's normal BSD-3-cause. I think there should be no problem.
>>> Of course, I can change the license if needed.
>>>
>>>
>>>>> 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.
>>>
>>> right.
>>>
>>>
>>>> 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.
>>>
>>> Automatic selection feature may become unnecessary if we get a new
>>> configuration
>>> interface.
>>>
>>> However, we still need a way showing a recommended IMF or combination
>>> of IMF and engines,
>>> which depends on the current locale.
>>>
>>> Note that there are (still) input methods that does not depend on
>>> any IMF such as Fcitx nor IBus.
>>>
>>> An example is Hime, which is the default IM for zh_TW.
>>> Mozc might become a such type of IM after the IBus support is dropped.
>>
>> Woo hoo, that's an interesting move...
>>
>>> Freedom sometimes limit smartness...
>>
>> Yes, as always :)
>>
>> I thought somehow the things get merged to the common IMF, but it
>> doesn't look happening so much yet.  If so, having a selection
>> mechanism per locale is still worth, IMO.  It makes things slightly
>> more complex, but not too much.  The complexity in the packaging side
>> can be avoided by providing a helper macro, for example.
>>
>>
>>>>> 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/*.
>>>
>>> I assume that the scripts are contained by every IMF package.
>>>
>>> Now I cannot do so, there are subpackages of chameleon-tongue:
>>> https://build.opensuse.org/package/view_file/home:ftake:branches:M17N/chameleon-tongue/chameleon-tongue.spec?expand=1
>>>
>>>
>>>
>>> If chameleon-tongue keep some catalog of input methods, then it can
>>> help users
>>> to install required packages.
>>>
>>> It will be a nice feature to me.
Mr Fuminobu TAKEYAMA:
I'm still interesting on how this feature was designed.
What is the method  you help users to install required packages?
Chameleon-tongue subpackage's dependences, or any other way?
Then what about uninstallation?  I think it's also a nice feature.
>>
>> Do you mean that it will help for users to choose the primary IMF at
>> installation?  I don't get exactly in which situation you supposed.
I'm also interested about this, Could you give me some detail?
>>
>> So far, we have a list of packages from locale Recommends tag of each
>> package.  Certainly, there is no list of IMFs or IMs.  (I don't think
>> we have a package group, either?)  From that POV, I would understand
>> such a need...
>>
>>
>> thanks,
>>
>> Takashi
>>
-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]