[opensuse-m17n] Does our xim process need an update?
M17N team members: hi! I'm handling with ibus debug works on SLED(S)now, and I'm new to SUSE M17N strategy, but I have this question as subject. Current situation: Our IM server start like this: 1) System boot, Then xinit launch /etc/X11/xim to start an IM server. 2) Get /etc/sysconfig/language IM server selection. This changes the default for all users. 3) If user define "INPUT_METHOD" in ~/.profile, then select IM server by it, and ignore step2's setting for current user; 4) Regardless the result step2 and step3, xim will start IM server by current user's language. This xim script is written in 10 years ago, something have changed in these days. For step3, It's better to move customer definition to a special file, like ~/.inputmethod or ~/.config/.inputmethod. Because it's hard for a program to change, especially when customer have written complex code flow in ~/.profile . Reference to: Bug 899259 - SLES12-RC3 ibus-setup pop up not working in Chinese, Korean, and Russian Mr Takashi Iwai point out this very clearly. For step4: I think it's unnecessary in future. Resons: 1, IM Server & IM Engine are different. A certain kind of IM server, like ibus, fcitx, scim, can supporting many kind of IM Engines. With these engine, people input in different language in the same server. Select IM Server by LANG is meaningless. 2, Default IM server is supposed to put in "/etc/sysconfig/language". it is defined during system installation. User custom IM server is supposed written in "~/.inputmethod" or "~/.config/.inputmethod." No need to be judged every time system start. 4, We will have only 1 IM server installed in future. Reference to: Fate 319095: deprecate fcitx chinese input method in favor of ibus. If customer installed another IM server after installation, then they can active one in custom file. 5, In early times, We have a dead key bug Bug 702064 - Dead keys don't work - https://bugzilla.novell.com/show_bug.cgi?id=702064 It's already have fixed patch and don't have reproduced yet, and I have test ibus with many language, So it won't influence. In that way, we don't need to select an IM server for customer by LANG env. For IM engines: 1, Users are supposed to select their IM Engine in "All Settings"->"Region & Language". Then System record his selection, active this selection at next time he login gnome. 2, Then how to define user input method for the first time login? I think the answer is "gnome-initial-setup". And there are also some other desktop and service settings need to be collect before customer first login, these settings are hard to guess, Some distribution already have use it, and it's the GNOME suggest method. 3, What I want to say is, gnome-initial-setup, Region_Language, ~/.inputmethod, and /etc/sysconfig/language can serve any people with any input scenario they want. Qiang Zhao
Hi, As you say, there are many issues and challenges with the way to start IMs. For example: - User-friendly IMs and IM frameworks selection - GNOME3 support - Kimpanel support - OOO_FORCE_DESKTOP - default settings of frameworks (such as Fcitx and IBus) depending on locale (Fcitx provides too many features for Chinese, which might be annoying for Japanese) - User-level IM settings v.s. system-wide IM settings - D-Bus server requirements - choosing input method frameworks after new one is installed With similar motivation, I am trying to implement a prototype of a new script: https://github.com/ftake/chameleon-tongue/ Let's discuss and improve input methods. Fuminobu Takeyama On 2015/07/10 22:29, Qiang Zhao wrote:
M17N team members: hi! I'm handling with ibus debug works on SLED(S)now, and I'm new to SUSE M17N strategy, but I have this question as subject. *Current situation:* Our IM server start like this: 1) System boot, Then xinit launch /etc/X11/xim to start an IM server. 2) Get /etc/sysconfig/language IM server selection. This changes the default for all users. 3) If user define "INPUT_METHOD" in ~/.profile, then select IM server by it, and ignore step2's setting for current user; 4) Regardless the result step2 and step3, xim will start IM server by current user's language. This xim script is written in 10 years ago, something have changed in these days.
*For step3, * It's better to move customer definition to a special file, like ~/.inputmethod or ~/.config/.inputmethod. Because it's hard for a program to change, especially when customer have written complex code flow in ~/.profile . Reference to: Bug 899259 - SLES12-RC3 ibus-setup pop up not working in Chinese, Korean, and Russian Mr Takashi Iwai point out this very clearly.
*For step4:* I think it's unnecessary in future. Resons: 1, IM Server & IM Engine are different. A certain kind of IM server, like ibus, fcitx, scim, can supporting many kind of IM Engines. With these engine, people input in different language in the same server. Select IM Server by LANG is meaningless.
2, Default IM server is supposed to put in "/etc/sysconfig/language". it is defined during system installation. User custom IM server is supposed written in "~/.inputmethod" or "~/.config/.inputmethod." No need to be judged every time system start.
4, We will have only 1 IM server installed in future. Reference to: Fate 319095: deprecate fcitx chinese input method in favor of ibus. If customer installed another IM server after installation, then they can active one in custom file.
5, In early times, We have a dead key bug Bug 702064 - Dead keys don't work - https://bugzilla.novell.com/show_bug.cgi?id=702064 It's already have fixed patch and don't have reproduced yet, and I have test ibus with many language, So it won't influence.
In that way, we don't need to select an IM server for customer by LANG env.
*For IM engines:* 1, Users are supposed to select their IM Engine in "All Settings"->"Region & Language". Then System record his selection, active this selection at next time he login gnome. 2, Then how to define user input method for the first time login? I think the answer is "gnome-initial-setup". And there are also some other desktop and service settings need to be collect before customer first login, these settings are hard to guess, Some distribution already have use it, and it's the GNOME suggest method. 3, What I want to say is, gnome-initial-setup, Region_Language, ~/.inputmethod, and /etc/sysconfig/language can serve any people with any input scenario they want.
Qiang Zhao -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Sun, 12 Jul 2015 17:35:22 +0200, Fuminobu TAKEYAMA wrote:
Hi,
As you say, there are many issues and challenges with the way to start IMs.
For example: - User-friendly IMs and IM frameworks selection - GNOME3 support - Kimpanel support - OOO_FORCE_DESKTOP - default settings of frameworks (such as Fcitx and IBus) depending on locale (Fcitx provides too many features for Chinese, which might be annoying for Japanese) - User-level IM settings v.s. system-wide IM settings - D-Bus server requirements - choosing input method frameworks after new one is installed
With similar motivation, I am trying to implement a prototype of a new script: https://github.com/ftake/chameleon-tongue/
This looks interesting. So this basically inherits the way to select the default IM framework per locale priority list, while the setup is split to several files. Using a symlink for pointing the use and system preference is a good idea. Below are some concerns and suggestions that came to my mind after a quick glance of the github repo: - Migration from old /etc/X11/xim setup; we need to keep the setup as much as possible. How can it be done gracefully? - 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. - Is the start of daemon solely done by the desktop file? What if a bare DE that doesn't start desktop files? - The ugly g-s-d workaround: can we implement this in a bit smarter way once when we redesign the framework? - It would be safer if we can avoid python for select-im... Otherwise python becomes mandatory for the whole system even for a minimal setup. thanks, Takashi
Let's discuss and improve input methods.
Fuminobu Takeyama
On 2015/07/10 22:29, Qiang Zhao wrote:
M17N team members: hi! I'm handling with ibus debug works on SLED(S)now, and I'm new to SUSE M17N strategy, but I have this question as subject. *Current situation:* Our IM server start like this: 1) System boot, Then xinit launch /etc/X11/xim to start an IM server. 2) Get /etc/sysconfig/language IM server selection. This changes the default for all users. 3) If user define "INPUT_METHOD" in ~/.profile, then select IM server by it, and ignore step2's setting for current user; 4) Regardless the result step2 and step3, xim will start IM server by current user's language. This xim script is written in 10 years ago, something have changed in these days.
*For step3, * It's better to move customer definition to a special file, like ~/.inputmethod or ~/.config/.inputmethod. Because it's hard for a program to change, especially when customer have written complex code flow in ~/.profile . Reference to: Bug 899259 - SLES12-RC3 ibus-setup pop up not working in Chinese, Korean, and Russian Mr Takashi Iwai point out this very clearly.
*For step4:* I think it's unnecessary in future. Resons: 1, IM Server & IM Engine are different. A certain kind of IM server, like ibus, fcitx, scim, can supporting many kind of IM Engines. With these engine, people input in different language in the same server. Select IM Server by LANG is meaningless.
2, Default IM server is supposed to put in "/etc/sysconfig/language". it is defined during system installation. User custom IM server is supposed written in "~/.inputmethod" or "~/.config/.inputmethod." No need to be judged every time system start.
4, We will have only 1 IM server installed in future. Reference to: Fate 319095: deprecate fcitx chinese input method in favor of ibus. If customer installed another IM server after installation, then they can active one in custom file.
5, In early times, We have a dead key bug Bug 702064 - Dead keys don't work - https://bugzilla.novell.com/show_bug.cgi?id=702064 It's already have fixed patch and don't have reproduced yet, and I have test ibus with many language, So it won't influence.
In that way, we don't need to select an IM server for customer by LANG env.
*For IM engines:* 1, Users are supposed to select their IM Engine in "All Settings"->"Region & Language". Then System record his selection, active this selection at next time he login gnome. 2, Then how to define user input method for the first time login? I think the answer is "gnome-initial-setup". And there are also some other desktop and service settings need to be collect before customer first login, these settings are hard to guess, Some distribution already have use it, and it's the GNOME suggest method. 3, What I want to say is, gnome-initial-setup, Region_Language, ~/.inputmethod, and /etc/sysconfig/language can serve any people with any input scenario they want.
Qiang Zhao -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
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. 2, The bin floder have 2 scripts, select-im is written in python, but start-im is written in bash; Maybe keep consistent is better. 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. 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. 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. If there are anything wrong please correct me. Thanks! Qiang Zhao
Takashi Iwai <tiwai@suse.de> 07/13/15 11:15 PM >>> On Sun, 12 Jul 2015 17:35:22 +0200, Fuminobu TAKEYAMA wrote:
Hi,
As you say, there are many issues and challenges with the way to start IMs.
For example: - User-friendly IMs and IM frameworks selection - GNOME3 support - Kimpanel support - OOO_FORCE_DESKTOP - default settings of frameworks (such as Fcitx and IBus) depending on locale (Fcitx provides too many features for Chinese, which might be annoying for Japanese) - User-level IM settings v.s. system-wide IM settings - D-Bus server requirements - choosing input method frameworks after new one is installed
With similar motivation, I am trying to implement a prototype of a new script: https://github.com/ftake/chameleon-tongue/
This looks interesting. So this basically inherits the way to select the default IM framework per locale priority list, while the setup is split to several files. Using a symlink for pointing the use and system preference is a good idea.
Below are some concerns and suggestions that came to my mind after a quick glance of the github repo:
- Migration from old /etc/X11/xim setup; we need to keep the setup as much as possible. How can it be done gracefully?
- 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.
- Is the start of daemon solely done by the desktop file? What if a bare DE that doesn't start desktop files?
- The ugly g-s-d workaround: can we implement this in a bit smarter way once when we redesign the framework?
- It would be safer if we can avoid python for select-im... Otherwise python becomes mandatory for the whole system even for a minimal setup.
thanks,
Takashi
Let's discuss and improve input methods.
Fuminobu Takeyama
On 2015/07/10 22:29, Qiang Zhao wrote:
M17N team members: hi! I'm handling with ibus debug works on SLED(S)now, and I'm new to SUSE M17N strategy, but I have this question as subject. *Current situation:* Our IM server start like this: 1) System boot, Then xinit launch /etc/X11/xim to start an IM server. 2) Get /etc/sysconfig/language IM server selection. This changes the default for all users. 3) If user define "INPUT_METHOD" in ~/.profile, then select IM server by it, and ignore step2's setting for current user; 4) Regardless the result step2 and step3, xim will start IM server by current user's language. This xim script is written in 10 years ago, something have changed in these days.
*For step3, * It's better to move customer definition to a special file, like ~/.inputmethod or ~/.config/.inputmethod. Because it's hard for a program to change, especially when customer have written complex code flow in ~/.profile . Reference to: Bug 899259 - SLES12-RC3 ibus-setup pop up not working in Chinese, Korean, and Russian Mr Takashi Iwai point out this very clearly.
*For step4:* I think it's unnecessary in future. Resons: 1, IM Server & IM Engine are different. A certain kind of IM server, like ibus, fcitx, scim, can supporting many kind of IM Engines. With these engine, people input in different language in the same server. Select IM Server by LANG is meaningless.
2, Default IM server is supposed to put in "/etc/sysconfig/language". it is defined during system installation. User custom IM server is supposed written in "~/.inputmethod" or "~/.config/.inputmethod." No need to be judged every time system start.
4, We will have only 1 IM server installed in future. Reference to: Fate 319095: deprecate fcitx chinese input method in favor of ibus. If customer installed another IM server after installation, then they can active one in custom file.
5, In early times, We have a dead key bug Bug 702064 - Dead keys don't work - https://bugzilla.novell.com/show_bug.cgi?id=702064 It's already have fixed patch and don't have reproduced yet, and I have test ibus with many language, So it won't influence.
In that way, we don't need to select an IM server for customer by LANG env.
*For IM engines:* 1, Users are supposed to select their IM Engine in "All Settings"->"Region & Language". Then System record his selection, active this selection at next time he login gnome. 2, Then how to define user input method for the first time login? I think the answer is "gnome-initial-setup". And there are also some other desktop and service settings need to be collect before customer first login, these settings are hard to guess, Some distribution already have use it, and it's the GNOME suggest method. 3, What I want to say is, gnome-initial-setup, Region_Language, ~/.inputmethod, and /etc/sysconfig/language can serve any people with any input scenario they want.
Qiang Zhao -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
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 floder 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? 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.)
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.
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
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. 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.
- 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.
- 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.
- 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.
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. Freedom sometimes limit smartness...
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. Thanks, Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
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
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/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
在 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/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. 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: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi, Well, that is a simple idea and not designed in detail. Assume that a user switch to Fcitx from IBus from a dialog of chameleon-tongue. If fcitx is not installed, chameleon-tongue ask if he wants to install fcitx. To do that, chameleon have to know what IMFs or IMs are available under openSUSE. The list of IMFs and IMs can be packaged within chameleon-tongue. It also can be retrieved from the package manager.
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?
That is not my idea. I think chameleon-tongue should allow users to choose IMF and IMs at the first login. Fuminobu Takeyama On 2015/07/20 19:04, Qiang Zhao wrote:
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... -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Mon, 20 Jul 2015 16:30:19 +0200, Fuminobu TAKEYAMA wrote:
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?
That is not my idea. I think chameleon-tongue should allow users to choose IMF and IMs at the first login.
Hmm, but how would it ask practically? We need to determine the IMF at the very beginning of X session. Does it kick off an X client program to let user select? But it's before the window manager or other setup gets started, so something weird may happen easily... thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
But it's before the window manager or other setup gets started, so something weird may happen easily...
That's why chameleon-tongue is launched by XDG autostart. I know if some settings was changed by chameleon tongue, the user have to log out the session, unfortunately. On 2015/07/20 23:51, Takashi Iwai wrote:
On Mon, 20 Jul 2015 16:30:19 +0200, Fuminobu TAKEYAMA wrote:
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?
That is not my idea. I think chameleon-tongue should allow users to choose IMF and IMs at the first login.
Hmm, but how would it ask practically? We need to determine the IMF at the very beginning of X session. Does it kick off an X client program to let user select? But it's before the window manager or other setup gets started, so something weird may happen easily...
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Mon, 20 Jul 2015 16:57:04 +0200, Fuminobu TAKEYAMA wrote:
But it's before the window manager or other setup gets started, so something weird may happen easily...
That's why chameleon-tongue is launched by XDG autostart.
So, IM at the very first login won't work? The autostart phase is already after the environment variable setup.
I know if some settings was changed by chameleon tongue, the user have to log out the session, unfortunately.
I think this is understandable for many users (although annoying). But if we force users to relogin for activating IM at the first login, its annoyance factor appears higher. thanks, Takashi
On 2015/07/20 23:51, Takashi Iwai wrote:
On Mon, 20 Jul 2015 16:30:19 +0200, Fuminobu TAKEYAMA wrote:
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?
That is not my idea. I think chameleon-tongue should allow users to choose IMF and IMs at the first login.
Hmm, but how would it ask practically? We need to determine the IMF at the very beginning of X session. Does it kick off an X client program to let user select? But it's before the window manager or other setup gets started, so something weird may happen easily...
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
在 2015年07月20日 23:08, Takashi Iwai 写道:
On Mon, 20 Jul 2015 16:57:04 +0200, Fuminobu TAKEYAMA wrote:
But it's before the window manager or other setup gets started, so something weird may happen easily...
That's why chameleon-tongue is launched by XDG autostart.
So, IM at the very first login won't work? The autostart phase is already after the environment variable setup.
I know if some settings was changed by chameleon tongue, the user have to log out the session, unfortunately.
I think this is understandable for many users (although annoying). But if we force users to relogin for activating IM at the first login, its annoyance factor appears higher.
thanks,
Takashi
Assume that a user switch to Fcitx from IBus from a dialog of chameleon-tongue. If fcitx is not installed, chameleon-tongue ask if he wants to install fcitx. It's better to active Fcitx at same time. Only a installation will make
1, At this point, I still l don't get the reason why we deprecate gnome-initial-setup, Or create another program like first-boot(fedora), to take the position? Because it can fix the functionality blank. 2, Another way is create a selection table on GDM. it will call chameleon tongue's desktop file later when customer successfully login. people confused. Qiang -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
That's why chameleon-tongue is launched by XDG autostart.
So, IM at the very first login won't work? The autostart phase is already after the environment variable setup.
On this point, the default settings should be "auto select depending on the current locale" so far.
But if we force users to relogin for activating IM at the first login, its annoyance factor appears higher.
If they are OK with the result of "auto select", they can go on without relogin. If not, they customize IMs and logout ... maybe after finishing online update. # setting for live USB users is another issue
1, At this point, I still l don't get the reason why we deprecate gnome-initial-setup, Or create another program like first-boot(fedora), to take the position?
If we considered only IBus and GNOME, gnome-initial-setup would be enough.
2, Another way is create a selection table on GDM. it will call chameleon tongue's desktop file later when customer successfully login.
That sounds interesting. Do you change lightdm, sddm, kdm, xdm as well as GDM? This approach might be easier for Ubuntu because we need to take care only lightdm. Fuminobu Takeyama On 2015/07/21 15:57, Qiang Zhao wrote:
在 2015年07月20日 23:08, Takashi Iwai 写道:
On Mon, 20 Jul 2015 16:57:04 +0200, Fuminobu TAKEYAMA wrote:
But it's before the window manager or other setup gets started, so something weird may happen easily...
That's why chameleon-tongue is launched by XDG autostart.
So, IM at the very first login won't work? The autostart phase is already after the environment variable setup.
I know if some settings was changed by chameleon tongue, the user have to log out the session, unfortunately.
I think this is understandable for many users (although annoying). But if we force users to relogin for activating IM at the first login, its annoyance factor appears higher.
thanks,
Takashi
1, At this point, I still l don't get the reason why we deprecate gnome-initial-setup, Or create another program like first-boot(fedora), to take the position? Because it can fix the functionality blank. 2, Another way is create a selection table on GDM. it will call chameleon tongue's desktop file later when customer successfully login.
Assume that a user switch to Fcitx from IBus from a dialog of chameleon-tongue. If fcitx is not installed, chameleon-tongue ask if he wants to install fcitx. It's better to active Fcitx at same time. Only a installation will make people confused.
Qiang -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
> 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: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
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 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: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
在 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. 2, The "auto select" is not necessary; 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.) Or create another program to take the position. 2, Create a selection table on GDM. it will call chameleon tongue's desktop file later when customer successfully login. 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: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
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?
> 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...
> 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.
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.
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.
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: opensuse-m17n+unsubscribe@opensuse.org
> To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
>
--
To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
> 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.
>
>> 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.
>
> 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
>
> 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: opensuse-m17n+unsubscribe@opensuse.org
>> To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
>>
>
--
To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
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: opensuse-m17n+unsubscribe@opensuse.org
> >> To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
> >>
> >
>
--
To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
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: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
在 2015年07月29日 14:35, Takashi Iwai 写道:
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.
I have reread your e-mail: If users don't care the difference of IMS, they will also don't care be assigned an pre defined IMF too, in this way, we don't need auto select. I want clear that the "auto select" we discuss here means select an IMF base user's LANG env. For SLE: Because of we only keep only 1 IMF installed by default in the feature we metioned, So run auto select at first time login is not useful. if user install another IMF from source, he will make a switch to new IMF or not only by their own favor. For your previous idea: We don't need to modify SLE installation program, because only 1IMF install by default, so user don't need to select. I think Add a dialog in "Settings" -> "region &language" is fine, user can install other IMF and switch if they need; For OpenSUSE, hope can insist on your previous decision, because it's far more better than current. But if you install 2 or more IMF in system installation, Maybe you still need modify installation program. -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Sun, 02 Aug 2015 10:43:18 +0200, Qiang Zhao wrote:
在 2015年07月29日 14:35, Takashi Iwai 写道:
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.
I have reread your e-mail: If users don't care the difference of IMS, they will also don't care be assigned an pre defined IMF too, in this way, we don't need auto select. I want clear that the "auto select" we discuss here means select an IMF base user's LANG env.
Maybe this definition of "auto select" misleads the discussion. In general, "auto select" is the way to select the default IMF without user's explicit interaction. Thus, the auto select is more or less mandatory for normal systems with multiple choices. If your suggestion is only about locale-specific auto select, then it might be worth to discuss. The question is what would the advantage of dropping per-locale selection be. Is it a reduction of maintenance cost? Well, I don't think it has been so big burden, so far. It's rather a once-off thing. A reduction of code complexity? This might be a good argument, especially if a new framework is developed. OTOH, Takeyama-san already implemented this, so is it worth to modify / drop again? Meanwhile, looking at the development history, you can find a different POV to this. The per-locale auto select made it possible to choose an IMF depending on the support status. For example, fcitx was chosen as a default IMF for Chinese because it has been more widely tested in that locale although it was new. For other locales, ibus was kept as default because it has been longer used. The per-locale selection has some practical merits (more flexibility) in that regard. So far, all what I wanted to say is that we need serious evaluations of such merits and demerits in order to judge whether to drop a feature. If you have another good argument, we'd happily listen to it, of course. Let's enjoy discussions!
For SLE: Because of we only keep only 1 IMF installed by default in the feature we metioned, So run auto select at first time login is not useful. if user install another IMF from source, he will make a switch to new IMF or not only by their own favor.
For your previous idea: We don't need to modify SLE installation program, because only 1IMF install by default, so user don't need to select. I think Add a dialog in "Settings" -> "region &language" is fine, user can install other IMF and switch if they need;
Right. One nice feature I'd hope is the inquiry and installation of IMF packages in this YaST module. We may provide some tags in each package to advertise itself, so that user can query and list up packages via zypper.
For OpenSUSE, hope can insist on your previous decision, because it's far more better than current. But if you install 2 or more IMF in system installation, Maybe you still need modify installation program.
Yes, some tuning would be needed in anyway for the migration. And, we must not underestimate this: the migration is one of the most important functions in the distribution after all... thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
You need answer to my question I sent you before. > 1, allow users to use some IMs before selecting IM at the first login is useful. What is some IMs? During this 10 years, auto selecting have been useful for many people. That's why I said a reasonable way to select the "some IMs" is the "auto selecting". > 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.) Are you sure that this means that we deprecates IM and IMFs (such as fcitx and hime) other than IBus? Fedora did because IBus is one of RedHad's products. They achieve that flexible settings of IM as your idea by selecting one input method framework. > 2, Create a selection table on GDM. it will call chameleon tongue's desktop file > later when customer successfully login. Do you change lightdm, sddm, kdm, xdm as well as GDM to ask IM to use? On 2015/07/27 22:12, 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. > 2, The "auto select" is not necessary; > 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.) > Or create another program to take the position. > 2, Create a selection table on GDM. it will call chameleon tongue's desktop file later when customer > successfully login. > > 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: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
> You need answer to my question I sent you before. > > > 1, allow users to use some IMs before selecting IM at the first login > is useful. > > What is some IMs? This sentence is copied from you email, I just reference it here. because I support it. > During this 10 years, auto selecting have been useful for many people. then, OK. Could you please show me your grounds, How you get this conclusion? > That's why I said a reasonable way to select the "some IMs" is the "auto > selecting". > > > > 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.) > > Are you sure that this means that we deprecates IM and IMFs (such as > fcitx and hime) other than IBus? You can see previous emails: Mr Takashi said we do not use gnome-initial-setup, and there already have a discussion. I said I don't find the record, and don't know the reason. For your question, I don't know what's your relationship between "gnome-initial-setup" and "deprecates IM and IMFs other than IBus", To tell the true, I still don't know. For below 2 question: What I want to discuss are features. We should make the final decision of features, then discuss the technical details, work load, child features under this decision. Right? > > Fedora did because IBus is one of RedHad's products. > They achieve that flexible settings of IM as your idea by selecting > one input method framework. Sure. I know that. I want to say is, if customer want to select IM, we can let them make selection on this point, instead of auto selection. Because we also can modify or extend or recreate our "gnome-initial-setup". > > > 2, Create a selection table on GDM. it will call chameleon tongue's > desktop file > > later when customer successfully login. > > Do you change lightdm, sddm, kdm, xdm as well as GDM to ask IM to use? What I want to discuss are features. We should provide the correct function to customer. that means we should select which your "*dm" is our support, and which is not. > > > On 2015/07/27 22:12, 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. >> 2, The "auto select" is not necessary; >> 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.) >> Or create another program to take the position. >> 2, Create a selection table on GDM. it will call chameleon tongue's >> desktop file later when customer >> successfully login. >> >> 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: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Wed, 29 Jul 2015 05:29:13 +0200, Qiang Zhao wrote: > > > > 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.) > > > > Are you sure that this means that we deprecates IM and IMFs (such as > > fcitx and hime) other than IBus? > You can see previous emails: > Mr Takashi said we do not use gnome-initial-setup, and there already > have a discussion. Note that the drop of gnome-initial-setup was about *only* SLE12. > I said I don't find the record, and don't know the reason. > For your question, I don't know what's your relationship between > "gnome-initial-setup" and "deprecates IM and IMFs other than IBus", > To tell the true, I still don't know. > > For below 2 question: > What I want to discuss are features. > We should make the final decision of features, then discuss the > technical details, work load, child features under this decision. Right? Well, no, other way round. Usually the decision comes at last. The decision has to be made after evaluating all details (from technical, political or whatever POVs) to judge whether it's feasible or not. It's same for FATE or any sane decision processes. > > > 2, Create a selection table on GDM. it will call chameleon tongue's > > desktop file > > > later when customer successfully login. > > > > Do you change lightdm, sddm, kdm, xdm as well as GDM to ask IM to use? > What I want to discuss are features. > We should provide the correct function to customer. that means we should > select which your "*dm" is our support, and which is not. All these DMs are supported on openSUSE. If anything doesn't work with them, it's flawed: either the framework has to be fixed or fix all DMs properly. If you suggestion is "make IMF selection mandatory at the (first) login", it means that we'll have to provide a way to achieve this as DM-agnostic, not depending on a single desktop environment. The use of gnome-initial-setup might help for GNOME. But then we still need to think the solutions for other DEs before moving to that direction. thanks, Takashi > > On 2015/07/27 22:12, 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. > >> 2, The "auto select" is not necessary; > >> 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.) > >> Or create another program to take the position. > >> 2, Create a selection table on GDM. it will call chameleon tongue's > >> desktop file later when customer > >> successfully login. > >> > >> 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: opensuse-m17n+unsubscribe@opensuse.org > To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org > -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
> Could you please show me your grounds, How you get this conclusion? >> That's why I said a reasonable way to select the "some IMs" is the "auto >> selecting". The system need to choose one (or some) IMs without users manual selection before asking their preferred IM. Is there any other idea than auto select? > For your question, I don't know what's your relationship between "gnome-initial-setup" and > "deprecates IM and IMFs other than IBus", > To tell the true, I still don't know. It provides mechanism so that users select ibus-* engines and ibus-xkb-* layouts only for GNOME desktop environment. It never supports IMFs such as Fcitx, Hime, Uim, etc.... > I want to say is, if customer want to select IM, we can let them make selection on this point, > instead of auto selection. There are technical difficulties since basically, users need relogin to select IMF, which requires to set new values to environment variables. # I'm not sure but is there any possibility to interrupt X start up and run some # applications before starting a desktop environment? > What I want to discuss are features. The feature we should provide is a mechanism to select preferred IM (and/or IMF) at the first login or an earlier phase. It's simple and clear, right? Fuminobu TAKEYAMA On 2015/07/29 12:29, Qiang Zhao wrote: >> You need answer to my question I sent you before. >> >> > 1, allow users to use some IMs before selecting IM at the first login >> is useful. >> >> What is some IMs? > This sentence is copied from you email, I just reference it here. because I support it. > >> During this 10 years, auto selecting have been useful for many people. > then, OK. > Could you please show me your grounds, How you get this conclusion? >> That's why I said a reasonable way to select the "some IMs" is the "auto >> selecting". > >> >> >> > 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.) >> >> Are you sure that this means that we deprecates IM and IMFs (such as >> fcitx and hime) other than IBus? > You can see previous emails: > Mr Takashi said we do not use gnome-initial-setup, and there already have a discussion. > I said I don't find the record, and don't know the reason. > For your question, I don't know what's your relationship between "gnome-initial-setup" and > "deprecates IM and IMFs other than IBus", > To tell the true, I still don't know. > > For below 2 question: > What I want to discuss are features. > We should make the final decision of features, then discuss the technical details, work load, child > features under this decision. Right? >> >> Fedora did because IBus is one of RedHad's products. >> They achieve that flexible settings of IM as your idea by selecting >> one input method framework. > Sure. I know that. > I want to say is, if customer want to select IM, we can let them make selection on this point, > instead of auto selection. > Because we also can modify or extend or recreate our "gnome-initial-setup". > >> >> > 2, Create a selection table on GDM. it will call chameleon tongue's >> desktop file >> > later when customer successfully login. >> >> Do you change lightdm, sddm, kdm, xdm as well as GDM to ask IM to use? > What I want to discuss are features. > We should provide the correct function to customer. that means we should select which your "*dm" is > our support, and which is not. > >> >> >> On 2015/07/27 22:12, 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. >>> 2, The "auto select" is not necessary; >>> 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.) >>> Or create another program to take the position. >>> 2, Create a selection table on GDM. it will call chameleon tongue's >>> desktop file later when customer >>> successfully login. >>> >>> 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: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
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
On Wed, 15 Jul 2015 14:41:01 +0200, Qiang Zhao wrote:
On Tue, 14 Jul 2015 07:44:10 +0200, Qiang Zhao wrote:
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.
Right. Currently "none" corresponds to XKB, as XKB is always there as default on X.
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?
This is no SUSE specific but rather an upstream work, so the question should be directed to the upstream devs :) I can imagine that Gtk IM switcher is feasible, but I'm not so certain whether this would be well received. It's technically interesting, but it leads to complexity (yeah, yet another layer).
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.
First off, I'm neutral about this, so the following is just my feeling: so far, the trend seems to move the start up things to desktop files as much as possible. It has a few merits: it allows parallel starts, allows masking a specific service by creating a dummy desktop file at $HOME, etc. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
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.
First off, I'm neutral about this, so the following is just my feeling: so far, the trend seems to move the start up things to desktop files as much as possible. It has a few merits: it allows parallel starts, allows masking a specific service by creating a dummy desktop file at $HOME, etc.
These days, DEs have become more and more complex. Launching X applications before DEs is sometimes troublesome. One cosmetic problem is that look-and-feel theme is not applied. Then, the current start up scripts of IMFs must start D-Bus daemon, which DEs will start later. This is why the upstream versions of IBus and Fcitx provide desktop files for xdg-autostart. XDG autostart is not a perfect solution. I am trying to check if Kimpanel is available or not before launching ibus-daemon. But there is no good way to assure the script starts after plasma applets. Fuminobu Takeyama On 2015年07月15日 22:12, Takashi Iwai wrote:
On Wed, 15 Jul 2015 14:41:01 +0200, Qiang Zhao wrote:
On Tue, 14 Jul 2015 07:44:10 +0200, Qiang Zhao wrote:
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.
Right. Currently "none" corresponds to XKB, as XKB is always there as default on X.
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?
This is no SUSE specific but rather an upstream work, so the question should be directed to the upstream devs :)
I can imagine that Gtk IM switcher is feasible, but I'm not so certain whether this would be well received. It's technically interesting, but it leads to complexity (yeah, yet another layer).
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.
First off, I'm neutral about this, so the following is just my feeling: so far, the trend seems to move the start up things to desktop files as much as possible. It has a few merits: it allows parallel starts, allows masking a specific service by creating a dummy desktop file at $HOME, etc.
thanks,
Takashi
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi, 0. Is there any way in shell script, that allows us to dynamically change input method framework without restart? That would be really awesome. 1. And I could not find the fate to deprecate fcitx, can somebody brief me? 2. chameleon-tongue should take GTK2/GTK3, QT4/QT5 into consideration, that is such env as GTK3_IM_MODULE :-) Marguerite -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi Marguerite,
0. Is there any way in shell script, that allows us to dynamically change input method framework without restart?
GTK and Qt applications can switch its IM. But I think there is no way to do from shell script. If we implement GTK IM module/Qt IM module/xim proxy, it could do that.
1. And I could not find the fate to deprecate fcitx, can somebody brief me?
I do not know any opinion to deprecate fcitx.
2. chameleon-tongue should take GTK2/GTK3, QT4/QT5 into consideration, that is such env as GTK3_IM_MODULE :-)
If some IMFs need it, it should support those environment variable. For example, ibus-mozc is buggy on Qt 5 application. So I maybe should set QT5_IM_MODULE=xim On 2015/07/16 0:51, Marguerite Su wrote:
Hi,
0. Is there any way in shell script, that allows us to dynamically change input method framework without restart?
That would be really awesome.
1. And I could not find the fate to deprecate fcitx, can somebody brief me?
2. chameleon-tongue should take GTK2/GTK3, QT4/QT5 into consideration, that is such env as GTK3_IM_MODULE :-)
Marguerite
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, Jul 16, 2015 at 9:26 PM, Fuminobu TAKEYAMA <ftake@geeko.jp> wrote:
0. Is there any way in shell script, that allows us to dynamically change input method framework without restart?
GTK and Qt applications can switch its IM. But I think there is no way to do from shell script.
If we implement GTK IM module/Qt IM module/xim proxy, it could do that.
our current discussion focus on to replace xim method w/ chameleon-tongue, and the most critical mission for all such technology is to properly set: export LC_CTYPE=$LANG export XMODIFIERS="@im=fcitx" export GTK_IM_MODULE=fcitx export GTK3_IM_MODULE=fcitx export QT_IM_SWITCHER=imsw-multi export QT_IM_MODULE=fcitx export QT4_IM_MODULE=fcitx to make input method framework take over users' input. and all such applications/ways can only set input method globally once at system boot (I might be wrong about this). after Xorg was started, there's no way to swich input method frameworks. My question is, is there such thing like: export FCITX_ENV=`/usr/lib/inputmethod/scripts/check_if_fcitx_is_running_and_prefered.sh` export GTK_IM_MODULE=$FCITX_ENV works. So when an application is started, it'll actually fetch GTK_IM_MODULE by running a script, which can check process of input method framework and /etc/sysconfig/inputmethod or something to find user preference. So you can switch from fcitx to ibus without the need to restart/logout. Or we have to write an special im module named "imfd" or something to dynamically set and load input method frameworks? BTW, I think along with shell scripts, ruby is also a good alternative, because every openSUSE installation have YaST and ruby :-) Marguerite -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, 16 Jul 2015 15:51:27 +0200, Marguerite Su wrote:
On Thu, Jul 16, 2015 at 9:26 PM, Fuminobu TAKEYAMA <ftake@geeko.jp> wrote:
0. Is there any way in shell script, that allows us to dynamically change input method framework without restart?
GTK and Qt applications can switch its IM. But I think there is no way to do from shell script.
If we implement GTK IM module/Qt IM module/xim proxy, it could do that.
our current discussion focus on to replace xim method w/ chameleon-tongue, and the most critical mission for all such technology is to properly set:
export LC_CTYPE=$LANG export XMODIFIERS="@im=fcitx" export GTK_IM_MODULE=fcitx export GTK3_IM_MODULE=fcitx export QT_IM_SWITCHER=imsw-multi export QT_IM_MODULE=fcitx export QT4_IM_MODULE=fcitx
to make input method framework take over users' input.
I thought GTK3_* and QT4_* are superfluous nowadays as Gtk3 and Qt4 look at GTK_* and QT_* variables as well?
and all such applications/ways can only set input method globally once at system boot (I might be wrong about this).
Not at boot, but at each X session / login.
after Xorg was started, there's no way to swich input method frameworks. My question is, is there such thing like:
export FCITX_ENV=`/usr/lib/inputmethod/scripts/check_if_fcitx_is_running_and_prefered.sh` export GTK_IM_MODULE=$FCITX_ENV
works. So when an application is started, it'll actually fetch GTK_IM_MODULE by running a script, which can check process of input method framework and /etc/sysconfig/inputmethod or something to find user preference. So you can switch from fcitx to ibus without the need to restart/logout.
I guess a wrapper like #!/bin/sh . /usr/lib/input-method/profile.d/auto/env exec "$@" would work. But it's doubtful whether such a dynamic switch is really demanded. Even with this mechanism, an application needs to be restart in anyway. If a DE has some session management, it can restart itself and restores the session after refreshing the IM-related environment variables.
Or we have to write an special im module named "imfd" or something to dynamically set and load input method frameworks?
BTW, I think along with shell scripts, ruby is also a good alternative, because every openSUSE installation have YaST and ruby :-)
Yes, but I don't think there won't be so complicated even in bash. Let's see. Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, Jul 16, 2015 at 10:06 PM, Takashi Iwai <tiwai@suse.de> wrote:
I thought GTK3_* and QT4_* are superfluous nowadays as Gtk3 and Qt4 look at GTK_* and QT_* variables as well?
I borrowed that setting from Debian a long time ago, so I have no idea what's going on now. Since you and Wengxt both said so, I think they're superfluous now.
I guess a wrapper like
#!/bin/sh . /usr/lib/input-method/profile.d/auto/env exec "$@"
would work. But it's doubtful whether such a dynamic switch is really demanded. Even with this mechanism, an application needs to be restart in anyway. If a DE has some session management, it can restart itself and restores the session after refreshing the IM-related environment variables.
You mean, just sourcing a script then everything will be all right? I'll test what you say...I'm not sure if DE session management will refresh itself when environment variable got changed Application restart is acceptable, I just don't want to relogin the DE... If so, can we leave some space for 3rd party to step in? because if input method framwork switch is doable, a YaST inputmethod won't be too far away :-) M -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, 16 Jul 2015 16:20:35 +0200, Marguerite Su wrote:
On Thu, Jul 16, 2015 at 10:06 PM, Takashi Iwai <tiwai@suse.de> wrote:
I thought GTK3_* and QT4_* are superfluous nowadays as Gtk3 and Qt4 look at GTK_* and QT_* variables as well?
I borrowed that setting from Debian a long time ago, so I have no idea what's going on now. Since you and Wengxt both said so, I think they're superfluous now.
I guess a wrapper like
#!/bin/sh . /usr/lib/input-method/profile.d/auto/env exec "$@"
would work. But it's doubtful whether such a dynamic switch is really demanded. Even with this mechanism, an application needs to be restart in anyway. If a DE has some session management, it can restart itself and restores the session after refreshing the IM-related environment variables.
You mean, just sourcing a script then everything will be all right?
I'll test what you say...I'm not sure if DE session management will refresh itself when environment variable got changed
Oh no, I meant to manually restart (re-login) DE with the session restore. This will actually restart everything in a shot.
Application restart is acceptable, I just don't want to relogin the DE...
But it will lead to inconsistency easily, e.g. some applications will keep running with the old IM that was already terminated while some new ones start using the new IM. In that sense, restarting all applications is a safer option -- which is equivalent as a re-login.
If so, can we leave some space for 3rd party to step in? because if input method framwork switch is doable, a YaST inputmethod won't be too far away :-)
Well, the idea is technically interesting, but this seems bringing more trouble than gain, so far. Most users don't care much about switching IMF, as long as its usability is kept, but rather more about IM engine... Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Thu, Jul 16, 2015 at 10:36 PM, Takashi Iwai <tiwai@suse.de> wrote:
Well, the idea is technically interesting, but this seems bringing more trouble than gain, so far. Most users don't care much about switching IMF, as long as its usability is kept, but rather more about IM engine...
Sure, most users don't care, but we M17N developers do care :-) Currently almost all IMF bugs go to me as bug owner in the end, so I myself actually need a technology to test IMF without relogin... And once some nerd users discussed about eg: use ibus-mozc and fcitx-sunpinyin together...so they can get the best user experience both on niconico and chinese microblog :-) So I think if there's solution existing by tweaks/combinations of current available technologies/applications, that would be a job worthly to be done, at least in my view :-) So in short my question is still: is it possible(no matter the inconsistency), like develop a wrapper to take over all the IMF env setting job and then pass through to applications. eg: just set a GTK_IM_MODULE=inputmethod-daemon and inputmethod-daemon will be fcitx/ibus/other IMFs. Marguerite -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
If you remember MS Windows, the environment variable under windows can be changed globally via their system settings. IIRC there are some desktop specific ways to set the environment variable for the application launcher (at least for gnome-settings-daemon?). In spite of desktop, dbus environment variable can be done via org.freedesktop.DBus.UpdateActivationEnvironment . But GTK_IM_MODULE is overriden by xsettings in GNOME 3.16, For Gtk under GNOME, you can use something like, and it will be changed at runtime without restart the application: gsettings set \ org.gnome.settings-daemon.plugins.xsettings overrides \ "{'Gtk/IMModule':<'fcitx'>}" For Qt, there's no way without restart the application, but as long as there's a way to the environment variable to the actual application launcher, it would be ok. For XIM case, the name in XMODIFIERS will be owned by im server, it's not possible to have two duplicate name on the same X. So for each im server, to use im specific name, or expect the have the same behavior as Qt (to restart the application). On Fri, Jul 17, 2015 at 8:42 PM, Marguerite Su <i@marguerite.su> wrote:
On Thu, Jul 16, 2015 at 10:36 PM, Takashi Iwai <tiwai@suse.de> wrote:
Well, the idea is technically interesting, but this seems bringing more trouble than gain, so far. Most users don't care much about switching IMF, as long as its usability is kept, but rather more about IM engine...
Sure, most users don't care, but we M17N developers do care :-)
Currently almost all IMF bugs go to me as bug owner in the end, so I myself actually need a technology to test IMF without relogin...
And once some nerd users discussed about eg: use ibus-mozc and fcitx-sunpinyin together...so they can get the best user experience both on niconico and chinese microblog :-)
So I think if there's solution existing by tweaks/combinations of current available technologies/applications, that would be a job worthly to be done, at least in my view :-)
So in short my question is still: is it possible(no matter the inconsistency), like develop a wrapper to take over all the IMF env setting job and then pass through to applications.
eg: just set a GTK_IM_MODULE=inputmethod-daemon and inputmethod-daemon will be fcitx/ibus/other IMFs.
Marguerite -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
在 2015年07月16日 21:26, Fuminobu TAKEYAMA 写道:
Hi Marguerite,
0. Is there any way in shell script, that allows us to dynamically change input method framework without restart?
GTK and Qt applications can switch its IM. But I think there is no way to do from shell script.
If we implement GTK IM module/Qt IM module/xim proxy, it could do that.
1. And I could not find the fate to deprecate fcitx, can somebody brief me?
I do not know any opinion to deprecate fcitx. It's not because of fate. fcitx is an excellent IM. The reason is, our ibus customer number is far more than fcitx in current. : -)
2. chameleon-tongue should take GTK2/GTK3, QT4/QT5 into consideration, that is such env as GTK3_IM_MODULE :-)
If some IMFs need it, it should support those environment variable. For example, ibus-mozc is buggy on Qt 5 application. So I maybe should set QT5_IM_MODULE=xim
On 2015/07/16 0:51, Marguerite Su wrote:
Hi,
0. Is there any way in shell script, that allows us to dynamically change input method framework without restart?
That would be really awesome.
1. And I could not find the fate to deprecate fcitx, can somebody brief me?
2. chameleon-tongue should take GTK2/GTK3, QT4/QT5 into consideration, that is such env as GTK3_IM_MODULE :-)
Marguerite
-- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Fri, 17 Jul 2015 05:58:41 +0200, Qiang Zhao wrote:
在 2015年07月16日 21:26, Fuminobu TAKEYAMA 写道:
Hi Marguerite,
0. Is there any way in shell script, that allows us to dynamically change input method framework without restart?
GTK and Qt applications can switch its IM. But I think there is no way to do from shell script.
If we implement GTK IM module/Qt IM module/xim proxy, it could do that.
1. And I could not find the fate to deprecate fcitx, can somebody brief me?
I do not know any opinion to deprecate fcitx. It's not because of fate. fcitx is an excellent IM. The reason is, our ibus customer number is far more than fcitx in current. : -)
FYI, it's FATE#319095, and note that it's targeted only for SLE12. For SLE12, this may make sense from the maintenance cost POV, as fcitx is installed only for Chinese locale as a stop gap. openSUSE is a completely different story. It's a different world and a different maintenance model. Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
On Fri, 17 Jul 2015 05:58:41 +0200, Qiang Zhao wrote:
在 2015年07月16日 21:26, Fuminobu TAKEYAMA 写道:
Hi Marguerite,
0. Is there any way in shell script, that allows us to dynamically change input method framework without restart?
GTK and Qt applications can switch its IM. But I think there is no way to do from shell script.
If we implement GTK IM module/Qt IM module/xim proxy, it could do that.
1. And I could not find the fate to deprecate fcitx, can somebody brief me?
I do not know any opinion to deprecate fcitx. It's not because of fate. fcitx is an excellent IM. The reason is, our ibus customer number is far more than fcitx in current. : -)
FYI, it's FATE#319095, and note that it's targeted only for SLE12. For SLE12, this may make sense from the maintenance cost POV, as fcitx is installed only for Chinese locale as a stop gap.
openSUSE is a completely different story. It's a different world and a different maintenance model.
Marguerite: Sorry, I misunderstanding your question. I mean it's not because of any bad advantage(feature) of fcitx. fcitx is an excellent IM. FATE URL: https://fate.suse.com/319095 For the maintenance cost POV reason, We only keep one IM by default, and others will keep in repos. We don't deprecate fcitx or any other IMs. And For the customer number reason, We select ibus as default. -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
Hi, Don't worry, I'm fine w/ ibus on SLE. Actually I knew that for nearly 2 years. Anyway it's much better than to maintain scim. The point I want to make was: the fate is not default to the public (keep inside SUSE and its customers), so we'd better not take it as reference/evidence. M. -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-m17n+owner@opensuse.org
participants (5)
-
Fuminobu TAKEYAMA -
Marguerite Su -
Qiang Zhao -
Takashi Iwai -
Weng Xuetian