[opensuse-m17n] Does our xim process need an update?

At Fri, 10 Jul 2015 15:29:21 +0200,

Post by Qiang Zhao
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.
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.

Post by Qiang Zhao
I think it's unnecessary in future.
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).

Post by Qiang Zhao
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?

Post by Qiang Zhao
In that way, we don't need to select an IM server for customer by LANG env.
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.

Post by Qiang Zhao
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-14 03:16:42 UTC

Sorry for replying so late,
The Beijing office's internet connection has broke up yesterday.
At Fri, 10 Jul 2015 15:29:21 +0200,

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?

In my opinion:
1, Other distribution switch IM function are quite different from each other.
Fedora/CentOS/RHEL use a imchooser GUI tool,
Debian/Ubuntu switch IM in âSettingsâ->"Region & Language" and âSettingsâââText EntryâGUI,
Some other distribution use env like:
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx
And also some distribution use desktop file:
cp /usr/share/applications/fcitx.desktop ~/.config/autostart/fcitx.desktop.
All of them have a lot bugs, and haven't repaired for a long time.
So I think there have not a common way to align with.

2, I think on the path ~/.config/inputmethod is better, because most of customer settings are saved here, this path will keep the consistency.

3, Using a symlink for pointing the use and system preference is a good idea indeed, this is an easy and solo method, and solve the priority problem ingenious.

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).

Hm, I haven't followed the recent ibus development, but was XKB
support in ibus already integrated, especially for SLE12 version?

Sorry, I'm not very clear about your âXKB support in ibusâ in detail.
Could you show me some more information?

Takashi Iwai

2015-07-14 13:58:51 UTC

Qiang, could you avoid HTML mail for posting to ML?
This makes hard to cite properly. Or, it'd be helpful to change the
way of citation.

In anyway, some more discussions below:

On Tue, 14 Jul 2015 05:16:42 +0200,

Post by Qiang Zhao
1, Other distribution switch IM function are quite different from each other.
Fedora/CentOS/RHEL use a imchooser GUI tool,
Debian/Ubuntu switch IM in “Settings”->"Region & Language" and “Settings”→”Text Entry”GUI,
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
cp /usr/share/applications/fcitx.desktop ~/.config/autostart/fcitx.desktop.
All of them have a lot bugs, and haven't repaired for a long time.
So I think there have not a common way to align with.

Fair enough.

Post by Qiang Zhao
2, I think on the path ~/.config/inputmethod is better, because most of customer settings are saved here, this path will keep the consistency.

OK.

Post by Qiang Zhao
3, Using a symlink for pointing the use and system preference is a good idea indeed, this is an easy and solo method, and solve the priority problem ingenious.

Yes.

Hm, I haven't followed the recent ibus development, but was XKB
support in ibus already integrated, especially for SLE12 version?

Sorry, I'm not very clear about your “XKB support in ibus” in detail.
Could you show me some more information?

There was an old bug in ibus that it didn't cover XKB well, leading to
the missing dead key support or making control-space breaking on
Emacs. This seems improved later, but I'm not sure how well XKB works
on top of ibus. So stated my question.

Speaking of XKB: in the past, the multiple keyboard layouts, e.g. for
Russian or Arabic, were switched directly on XKB, typically
Shift+Shift or Alt-Gr. Now this setup seems gone -- at least GNOME
doesn't provide any longer. Instead, GNOME supposes the switch of
multiple "Input Sources" where each of them is the specific XKB (or
ibus) keyboard layout. So, this is rather a radical redesign. And,
the question is whether other DEs follow this, too...

I hope I can know the reasons.
Is there any document link or any record left?

Might be somewhere in Bugzilla or ML archive...
IIRC, gnome-initial-setup was rejected on SLE12 because this caused
problems. It was invented after SLE12 GNOME version.

thanks,

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-15 12:48:48 UTC

Post by Takashi Iwai
Qiang, could you avoid HTML mail for posting to ML?
This makes hard to cite properly. Or, it'd be helpful to change the
way of citation.

I'm so sorry for that, And I switched from web to Mozilla Thunderbird,
Does it looks better this time?
Also apologize for so much typos on previous e-mails
: -)

Post by Takashi Iwai
On Tue, 14 Jul 2015 05:16:42 +0200,

Fair enough.

Post by Qiang Zhao
2, I think on the path ~/.config/inputmethod is better, because most of customer settings are saved here, this path will keep the consistency.

OK.

Post by Qiang Zhao
3, Using a symlink for pointing the use and system preference is a good idea indeed, this is an easy and solo method, and solve the priority problem ingenious.

Yes.

Hm, I haven't followed the recent ibus development, but was XKB
support in ibus already integrated, especially for SLE12 version?

Sorry, I'm not very clear about your “XKB support in ibus” in detail.
Could you show me some more information?

There was an old bug in ibus that it didn't cover XKB well, leading to
the missing dead key support or making control-space breaking on
Emacs. This seems improved later, but I'm not sure how well XKB works
on top of ibus. So stated my question.
Speaking of XKB: in the past, the multiple keyboard layouts, e.g. for
Russian or Arabic, were switched directly on XKB, typically
Shift+Shift or Alt-Gr. Now this setup seems gone -- at least GNOME
doesn't provide any longer. Instead, GNOME supposes the switch of
multiple "Input Sources" where each of them is the specific XKB (or
ibus) keyboard layout. So, this is rather a radical redesign. And,
the question is whether other DEs follow this, too...

OK, Thanks.

I hope I can know the reasons.
Is there any document link or any record left?

Might be somewhere in Bugzilla or ML archive...
IIRC, gnome-initial-setup was rejected on SLE12 because this caused
problems. It was invented after SLE12 GNOME version.

OK I will dig in them.
thanks!

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-15 13:13:14 UTC

On Wed, 15 Jul 2015 14:48:48 +0200,

Post by Takashi Iwai
Qiang, could you avoid HTML mail for posting to ML?
This makes hard to cite properly. Or, it'd be helpful to change the
way of citation.

I'm so sorry for that, And I switched from web to Mozilla Thunderbird,
Does it looks better this time?
Also apologize for so much typos on previous e-mails
: -)

It looks much better now, thanks!

Takashi

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2015-07-12 15:35:22 UTC

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

Post by Qiang Zhao
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:*
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.
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-13 15:15:03 UTC

On Sun, 12 Jul 2015 17:35:22 +0200,

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

Post by Fuminobu TAKEYAMA
Let's discuss and improve input methods.
Fuminobu Takeyama

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-14 05:44:10 UTC

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
On Sun, 12 Jul 2015 17:35:22 +0200,

Post by Fuminobu TAKEYAMA
Hi,
As you say, there are many issues and challenges with the way to start IMs.
- 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
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
- 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

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-14 14:20:54 UTC

On Tue, 14 Jul 2015 07:44:10 +0200,

Post by Qiang Zhao
What an excellent work you have done!
And please accept my respect!
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.

Post by Qiang Zhao
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.

Post by Qiang Zhao
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.)

Post by Qiang Zhao
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.

Post by Qiang Zhao
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2015-07-14 16:01:48 UTC

Hi,

Post by Takashi Iwai
- 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.

Post by Takashi Iwai
- 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!

Post by Takashi Iwai
- 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.

Post by Takashi Iwai
- 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.

Post by Takashi Iwai
- It would be safer if we can avoid python for select-im...

Post by Qiang Zhao
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.

Post by Takashi Iwai
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.

Post by Qiang Zhao
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.

Post by Takashi Iwai
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...

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/chameleon-tongue/chameleon-tongue.spec?expand=1

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

Takashi Iwai

2015-07-14 16:31:05 UTC

On Tue, 14 Jul 2015 18:01:48 +0200,

Post by Fuminobu TAKEYAMA
Hi,

Post by Takashi Iwai
- 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 :)

Post by Fuminobu TAKEYAMA
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.

Sounds good!

Post by Takashi Iwai
- Is the start of daemon solely done by the desktop file?
What if a bare DE that doesn't start desktop files?

OK, that's also my expectation.

Post by Takashi Iwai
- 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.

Post by Takashi Iwai
- It would be safer if we can avoid python for select-im...

Post by Qiang Zhao
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.

Post by Takashi Iwai
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.

Post by Qiang Zhao
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.

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...

Post by Fuminobu TAKEYAMA
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.

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.
https://build.opensuse.org/package/view_file/home:ftake:branches:M17N/chameleon-tongue/chameleon-tongue.spec?expand=1
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2015-07-15 14:38:20 UTC

Post by Takashi Iwai
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.

Post by Takashi Iwai
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.

Post by Takashi Iwai
On Tue, 14 Jul 2015 18:01:48 +0200,

Post by Fuminobu TAKEYAMA
Hi,

Post by Takashi Iwai
- 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.

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.

Sounds good!

Post by Takashi Iwai
- Is the start of daemon solely done by the desktop file?
What if a bare DE that doesn't start desktop files?

OK, that's also my expectation.

Post by Takashi Iwai
- 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.

Post by Takashi Iwai
- It would be safer if we can avoid python for select-im...

Post by Qiang Zhao
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.

Post by Takashi Iwai
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.

Post by Qiang Zhao
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.

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...

Post by Fuminobu TAKEYAMA
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.

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/*.

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

Qiang Zhao

2015-07-20 10:04:57 UTC

Post by Takashi Iwai
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.

Post by Takashi Iwai
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.

Post by Takashi Iwai
On Tue, 14 Jul 2015 18:01:48 +0200,

Post by Fuminobu TAKEYAMA
Hi,

Post by Takashi Iwai
- 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.

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.

Sounds good!

Post by Takashi Iwai
- 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.

Post by Takashi Iwai
- 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.

Post by Takashi Iwai
- It would be safer if we can avoid python for select-im...

Post by Qiang Zhao
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.

Post by Takashi Iwai
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.

Post by Qiang Zhao
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.

Post by Takashi Iwai
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...

Post by Fuminobu TAKEYAMA
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.

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/*.

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.

Post by Takashi Iwai
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?

Post by Takashi Iwai
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2015-07-20 14:30:19 UTC

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.

Post by Takashi Iwai
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

Post by Fuminobu TAKEYAMA
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.

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.

Post by Takashi Iwai
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?

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-20 14:51:59 UTC

On Mon, 20 Jul 2015 16:30:19 +0200,

Post by Takashi Iwai
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2015-07-20 14:57:04 UTC

Post by Takashi Iwai
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.

Post by Takashi Iwai
On Mon, 20 Jul 2015 16:30:19 +0200,

Post by Takashi Iwai
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.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-20 15:08:58 UTC

On Mon, 20 Jul 2015 16:57:04 +0200,

Post by Takashi Iwai
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.

Post by Fuminobu TAKEYAMA
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

Post by Takashi Iwai
On Mon, 20 Jul 2015 16:30:19 +0200,

Post by Takashi Iwai
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.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-21 06:57:15 UTC

Post by Takashi Iwai
On Mon, 20 Jul 2015 16:57:04 +0200,

Post by Takashi Iwai
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.

Post by Fuminobu TAKEYAMA
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.

Post by Takashi Iwai
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2015-07-21 14:39:12 UTC

Post by Fuminobu TAKEYAMA
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.

Post by Takashi Iwai
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

Post by Takashi Iwai
On Mon, 20 Jul 2015 16:57:04 +0200,

Post by Takashi Iwai
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.

Post by Fuminobu TAKEYAMA
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.

Post by Takashi Iwai
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-23 11:40:49 UTC

Post by Fuminobu TAKEYAMA
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

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my previous email.

Takashi

Post by Fuminobu TAKEYAMA
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.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always there as
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2015-07-26 07:37:57 UTC

I've understood your opinion.

We have started to discuss technical problems to realize our idea
including your "manually selecting IM name".

Post by Fuminobu TAKEYAMA
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

Post by Fuminobu TAKEYAMA
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

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my previous

email.
Takashi

- We still don't know which customer doesn't need more than XKB.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always there as
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-27 13:12:15 UTC

Post by Fuminobu TAKEYAMA
I've understood your opinion.
We have started to discuss technical problems to realize our idea
including your "manually selecting IM name".

Post by Fuminobu TAKEYAMA
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

Post by Fuminobu TAKEYAMA
to use.

Post by Fuminobu TAKEYAMA
On this point, the default settings should be "auto select

depending on

Post by Fuminobu TAKEYAMA
the current locale"
so far.

Sorry, I think I didn't express my thought very clearly, See the

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my previous

email.
Takashi

- We still don't know which customer doesn't need more than XKB.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always there as
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-27 13:32:29 UTC

On Mon, 27 Jul 2015 15:12:15 +0200,

Post by Fuminobu TAKEYAMA
I've understood your opinion.
We have started to discuss technical problems to realize our idea
including your "manually selecting IM name".

Post by Fuminobu TAKEYAMA
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

1, allow users to use some IMs before selecting IM at the first login is
useful.

Yes... and a bit of No. See below.

Post by Qiang Zhao
2, The "auto select" is not necessary;

Hmm, what if the system has two IMFs installed? Which one to take?

Post by Qiang Zhao
3, We must provide a mechanism to ask which IM the user wants.
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...

Post by Qiang Zhao
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.

Post by Qiang Zhao
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

Post by Qiang Zhao
Qiang Zhao

Post by Fuminobu TAKEYAMA
to use.

Post by Fuminobu TAKEYAMA
On this point, the default settings should be "auto select

depending on

Post by Fuminobu TAKEYAMA
the current locale"
so far.

Sorry, I think I didn't express my thought very clearly, See the

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my previous

email.
Takashi

- We still don't know which customer doesn't need more than XKB.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always there as
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-29 04:01:15 UTC

Post by Takashi Iwai
On Mon, 27 Jul 2015 15:12:15 +0200,

Post by Fuminobu TAKEYAMA
I've understood your opinion.
We have started to discuss technical problems to realize our idea
including your "manually selecting IM name".

Post by Fuminobu TAKEYAMA
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

1, allow users to use some IMs before selecting IM at the first login is
useful.

Yes... and a bit of No. See below.

Post by Qiang Zhao
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).

Post by Qiang Zhao
3, We must provide a mechanism to ask which IM the user wants.
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
- 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.

Post by Qiang Zhao
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.

Post by Qiang Zhao
2, Create a selection table on GDM. it will call chameleon tongue's
desktop file later when customer successfully login.

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.

Post by Takashi Iwai
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

Post by Takashi Iwai
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?

Post by Takashi Iwai
Takashi

Post by Qiang Zhao
Qiang Zhao

Post by Fuminobu TAKEYAMA
to use.

Post by Fuminobu TAKEYAMA
On this point, the default settings should be "auto select

depending on

Post by Fuminobu TAKEYAMA
the current locale"
so far.

Sorry, I think I didn't express my thought very clearly, See the

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my previous

email.
Takashi

- We still don't know which customer doesn't need more than XKB.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always there as
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-29 06:35:36 UTC

On Wed, 29 Jul 2015 06:01:15 +0200,

Post by Takashi Iwai
On Mon, 27 Jul 2015 15:12:15 +0200,

Post by Fuminobu TAKEYAMA
I've understood your opinion.
We have started to discuss technical problems to realize our idea
including your "manually selecting IM name".

Post by Fuminobu TAKEYAMA
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

1, allow users to use some IMs before selecting IM at the first login is
useful.

Yes... and a bit of No. See below.

Post by Qiang Zhao
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).

Post by Qiang Zhao
3, We must provide a mechanism to ask which IM the user wants.
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.)

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.

Post by Qiang Zhao
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.

Post by Qiang Zhao
2, Create a selection table on GDM. it will call chameleon tongue's
desktop file later when customer successfully login.

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.

But please note that "auto select" is another kind of "user choose IMF
explicitly".
1, /etc/sysconfig/language
2, auto select | customer select
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

I think "/etc/sysconfig/language" is his fallback.
And we do not need 2 layers of fallback right?

Post by Takashi Iwai
Takashi

Post by Qiang Zhao
Qiang Zhao

Post by Fuminobu TAKEYAMA
to use.

Post by Fuminobu TAKEYAMA
On this point, the default settings should be "auto select

depending on

Post by Fuminobu TAKEYAMA
the current locale"
so far.

Sorry, I think I didn't express my thought very clearly, See the

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my previous

email.
Takashi

- We still don't know which customer doesn't need more than XKB.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always there as
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-30 04:38:25 UTC

Post by Takashi Iwai
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.

Post by Takashi Iwai
On Wed, 29 Jul 2015 06:01:15 +0200,

Post by Takashi Iwai
On Mon, 27 Jul 2015 15:12:15 +0200,

Post by Fuminobu TAKEYAMA
I've understood your opinion.
We have started to discuss technical problems to realize our idea
including your "manually selecting IM name".

Post by Fuminobu TAKEYAMA
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

1, allow users to use some IMs before selecting IM at the first login is
useful.

Yes... and a bit of No. See below.

Post by Qiang Zhao
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).

Post by Qiang Zhao
3, We must provide a mechanism to ask which IM the user wants.
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.)

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.

Post by Qiang Zhao
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.

Post by Qiang Zhao
2, Create a selection table on GDM. it will call chameleon tongue's
desktop file later when customer successfully login.

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
whether to serve for majority or to save minority. There can be never
100% "correct" answer here.

But please note that "auto select" is another kind of "user choose IMF
explicitly".
1, /etc/sysconfig/language
2, auto select | customer select
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

I think "/etc/sysconfig/language" is his fallback.
And we do not need 2 layers of fallback right?

Post by Takashi Iwai
Takashi

Post by Qiang Zhao
Qiang Zhao

Post by Fuminobu TAKEYAMA
to use.

Post by Fuminobu TAKEYAMA
On this point, the default settings should be "auto select

depending on

Post by Fuminobu TAKEYAMA
the current locale"
so far.

Sorry, I think I didn't express my thought very clearly, See the

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my previous

email.
Takashi

- We still don't know which customer doesn't need more than XKB.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always there as
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-08-02 08:43:18 UTC

Post by Qiang Zhao
2, Create a selection table on GDM. it will call chameleon tongue's
desktop file later when customer successfully login.

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.

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

Takashi Iwai

2015-08-02 15:08:42 UTC

On Sun, 02 Aug 2015 10:43:18 +0200,

Post by Qiang Zhao
2, Create a selection table on GDM. it will call chameleon tongue's
desktop file later when customer successfully login.

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.

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!

Post by Qiang Zhao
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.
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.

Post by Qiang Zhao
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2015-07-28 12:52:49 UTC

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?

Post by Fuminobu TAKEYAMA
I've understood your opinion.
We have started to discuss technical problems to realize our idea
including your "manually selecting IM name".

Post by Fuminobu TAKEYAMA
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

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.
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

Post by Fuminobu TAKEYAMA
to use.

Post by Fuminobu TAKEYAMA
On this point, the default settings should be "auto select

depending on

Post by Fuminobu TAKEYAMA
the current locale"
so far.

Sorry, I think I didn't express my thought very clearly, See the

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my previous

email.
Takashi

- We still don't know which customer doesn't need more than XKB.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always there as
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-29 03:29:13 UTC

Post by Fuminobu TAKEYAMA
You need answer to my question I sent you before.

Post by Qiang Zhao
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.

Post by Fuminobu TAKEYAMA
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?

Post by Fuminobu TAKEYAMA
That's why I said a reasonable way to select the "some IMs" is the "auto selecting".

Post by Qiang Zhao
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?

Post by Fuminobu TAKEYAMA
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".

Post by Qiang Zhao
2, Create a selection table on GDM. it will call chameleon tongue's

desktop file

Post by Qiang Zhao
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.

Post by Fuminobu TAKEYAMA
I've understood your opinion.
We have started to discuss technical problems to realize our idea
including your "manually selecting IM name".

Post by Fuminobu TAKEYAMA
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

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.
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

Post by Fuminobu TAKEYAMA
to use.

Post by Fuminobu TAKEYAMA
On this point, the default settings should be "auto select

depending on

Post by Fuminobu TAKEYAMA
the current locale"
so far.

Sorry, I think I didn't express my thought very clearly, See the

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my

previous
email.
Takashi

fcitx

Post by Fuminobu TAKEYAMA
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.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always

there as

Post by Fuminobu TAKEYAMA
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-29 08:05:46 UTC

On Wed, 29 Jul 2015 05:29:13 +0200,

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?

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.

Post by Qiang Zhao
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.
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

Post by Fuminobu TAKEYAMA
I've understood your opinion.
We have started to discuss technical problems to realize our idea
including your "manually selecting IM name".

Post by Fuminobu TAKEYAMA
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

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.
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

Post by Fuminobu TAKEYAMA
to use.

Post by Fuminobu TAKEYAMA
On this point, the default settings should be "auto select

depending on

Post by Fuminobu TAKEYAMA
the current locale"
so far.

Sorry, I think I didn't express my thought very clearly, See the

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my

previous
email.
Takashi

fcitx

- We still don't know which customer doesn't need more than XKB.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always

there as

Post by Fuminobu TAKEYAMA
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2015-07-29 15:09:04 UTC

Post by Qiang Zhao
Could you please show me your grounds, How you get this conclusion?

Post by Fuminobu TAKEYAMA
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?

Post by Qiang Zhao
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....

Post by Qiang Zhao
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?

Post by Qiang Zhao
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

Post by Fuminobu TAKEYAMA
You need answer to my question I sent you before.

Post by Qiang Zhao
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.

Post by Fuminobu TAKEYAMA
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?

Post by Fuminobu TAKEYAMA
That's why I said a reasonable way to select the "some IMs" is the "auto selecting".

Post by Qiang Zhao
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?

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.
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?

Post by Fuminobu TAKEYAMA
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".

Post by Qiang Zhao
2, Create a selection table on GDM. it will call chameleon tongue's

desktop file

Post by Qiang Zhao
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.

Post by Fuminobu TAKEYAMA
I've understood your opinion.
We have started to discuss technical problems to realize our idea
including your "manually selecting IM name".

Post by Fuminobu TAKEYAMA
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

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.
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

Post by Fuminobu TAKEYAMA
to use.

Post by Fuminobu TAKEYAMA
On this point, the default settings should be "auto select

depending on

Post by Fuminobu TAKEYAMA
the current locale"
so far.

Sorry, I think I didn't express my thought very clearly, See the

Post by Fuminobu TAKEYAMA
3, Select the default IM framework base language(current locale) is

useless in my opinion,

Post by Fuminobu TAKEYAMA
So I think select-im only accept an IM name parameter, and set

for current user is enough.

Post by Fuminobu TAKEYAMA
also, no need to divide in locale.d sub-folders. See my

previous
email.
Takashi

fcitx

- We still don't know which customer doesn't need more than XKB.
+ We still don't know which customer only need XKB.

Post by Fuminobu TAKEYAMA
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"

Post by Fuminobu TAKEYAMA
Please notice that even we choose by locales, it will not always be

right.

Post by Fuminobu TAKEYAMA
Right. Currently "none" corresponds to XKB, as XKB is always

there as

Post by Fuminobu TAKEYAMA
default on X.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-15 12:41:01 UTC

Post by Takashi Iwai
On Tue, 14 Jul 2015 07:44:10 +0200,

Through a quick glance, it looks like a BSD 3-clause license, so it
should be fine, if it's really so.

Post by Qiang Zhao
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.

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.

Post by Takashi Iwai
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?

Post by Qiang Zhao
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.

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

Takashi Iwai

2015-07-15 13:12:08 UTC

On Wed, 15 Jul 2015 14:41:01 +0200,

Post by Takashi Iwai
On Tue, 14 Jul 2015 07:44:10 +0200,

Right. Currently "none" corresponds to XKB, as XKB is always there as
default on X.

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.
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).

Post by Qiang Zhao
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Fuminobu TAKEYAMA

2015-07-15 14:54:09 UTC

Post by Qiang Zhao
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.

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

Post by Takashi Iwai
On Wed, 15 Jul 2015 14:41:01 +0200,

Post by Takashi Iwai
On Tue, 14 Jul 2015 07:44:10 +0200,

Right. Currently "none" corresponds to XKB, as XKB is always there as
default on X.

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).

Post by Qiang Zhao
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.

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2015-07-15 15:51:09 UTC

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

Fuminobu TAKEYAMA

2015-07-16 13:26:37 UTC

Hi Marguerite,

Post by Marguerite Su
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.

Post by Marguerite Su
1. And I could not find the fate to deprecate fcitx, can somebody brief me?

I do not know any opinion to deprecate fcitx.

Post by Marguerite Su
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

Post by Marguerite Su
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2015-07-16 13:51:27 UTC

Post by Marguerite Su
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-16 14:06:27 UTC

On Thu, 16 Jul 2015 15:51:27 +0200,

Post by Marguerite Su

Post by Marguerite Su
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
export LC_CTYPE=$LANG
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?

Post by Marguerite Su
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.

Post by Marguerite Su
after Xorg was started, there's no
way to swich input method frameworks. My question is, is there such
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.

Post by Marguerite Su
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2015-07-16 14:20:35 UTC

Post by Takashi Iwai
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.

Post by Takashi Iwai
I guess a wrapper like
#!/bin/sh
. /usr/lib/input-method/profile.d/auto/env
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-16 14:36:12 UTC

On Thu, 16 Jul 2015 16:20:35 +0200,

Post by Marguerite Su

Post by Takashi Iwai
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.

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.

Post by Marguerite Su
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.

Post by Marguerite Su
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2015-07-18 03:42:26 UTC

Post by Takashi Iwai
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Weng Xuetian

2015-07-18 03:57:45 UTC

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).

Post by Marguerite Su

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

Qiang Zhao

2015-07-17 03:58:41 UTC

Post by Fuminobu TAKEYAMA
Hi Marguerite,

Post by Marguerite Su
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.

Post by Marguerite Su
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.
: -)

Post by Marguerite Su
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

--
To unsubscribe, e-mail: opensuse-m17n+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Takashi Iwai

2015-07-17 05:48:08 UTC

On Fri, 17 Jul 2015 05:58:41 +0200,

Post by Fuminobu TAKEYAMA
Hi Marguerite,

Post by Marguerite Su
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.

Post by Marguerite Su
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Qiang Zhao

2015-07-17 12:13:30 UTC

Post by Takashi Iwai
On Fri, 17 Jul 2015 05:58:41 +0200,

Post by Fuminobu TAKEYAMA
Hi Marguerite,

Post by Marguerite Su
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.

Post by Marguerite Su
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+***@opensuse.org
To contact the owner, e-mail: opensuse-m17n+***@opensuse.org

Marguerite Su

2015-07-18 03:27:10 UTC