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/chamel...
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.
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. 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: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org