openSUSE M17n July 2015

m17n@lists.opensuse.org

5 participants
2 discussions

[opensuse-m17n] Does our xim process need an update?
by Qiang Zhao 02 Aug '15

02 Aug '15

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

5 42

[opensuse-m17n] Re: Does our xim process need an update?
by Takashi Iwai 15 Jul '15

15 Jul '15

At Fri, 10 Jul 2015 15:29:21 +0200, 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. Qiang, thanks for heading up! As mentioned here, currently we have no common way to manage the user's selection of IM. We rely on either /etc/sysconfig/language setup via YaST sysconfig editor or manual setup of ~/.profile. Ideally, we'd need a program (both GUI and command-line) to manipulate such a setup. And for such, a separate file (like ~/.inputmethod) to contain the current IM framework would make the life easier. Here, the remaining questions are: - Are people happy with the addition of ~/.inputmethod? - What file name / path should be used? ~/.inputmethod, ~/.im, ~/.config/inputmethod, whatever? - Should we align this setup with other distros? - How this new setup should be evaluated? IOW, in which order should we evaluate $INPUT_METHOD? Currently, we evaluate $INPUT_METHOD from ~/.profile or such, then fallback to /etc/sysconfig/language. Should the new setup be the first priority, or evaluated after ~/.profile? > 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. This is really an open question. For SLED, it would make sense to concentrate only on a single IM for the ease of maintenance. But for openSUSE, I guess that we'd like rather to keep more freedom, and such an enforcement of a single IM framework won't be received well, especially judging from the current situation among ibus and fcitx (e.g. Ubuntu is going to switch fcitx as the default IM framework for CJK). > 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. Hm, I haven't followed the recent ibus development, but was XKB support in ibus already integrated, especially for SLE12 version? > 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". I thought this didn't work well in SLED12 version of GNOME? We had thought gnome-initial-setup could cover the startup issue, but I was informed somehow it couldn't get it in or had some issue. It's a pretty vague memory, so I might be wrong here. Frederic must know better on this. > 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. Well, we must not forget about other desktop environment, not only about GNOME. On openSUSE, KDE, XFCE and others must keep working. And, even on SLED, we still support icewm as a fallback desktop. The IM framework needs to work on it properly, too, and for such systems, some explicit way to setup / invoke IM is still needed. Actually, the IM setup isn't done in /etc/X11/xim in the case of ibus *and* GNOME. We skip explicitly there in an ugly way. And, I agree that the current implementation isn't optimal. For some systems, starting via desktop file makes more sense. OTOH, the setup of environment variables has to be still done there for non-GNOME systems, I suppose. In anyway, we need to refresh the requirement and possible improvement in each desktop... thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-m17n+owner(a)opensuse.org

2 4

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE M17n July 2015