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