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