Mailinglist Archive: opensuse-m17n (46 mails)

< Previous Next >
Re: [opensuse-m17n] Does our xim process need an update?
> One relevant question about the system setup: should we fix to an IM
> once when started/used, or keep it dynamically evaluated at every
> start?

I supposed that chameleon-tongue will show a dialogue or notification
if it detects a new IM.

If users have selected a specific IM before the change and ignore the notification, it does not change their setting.

> Do you mean that it will help for users to choose the primary IMF at
> installation? I don't get exactly in which situation you supposed.

No. It is just a naive feature that allows users to install packages
of IMs from an IM-setting dialog provided by chameleon-tongue.

On 2015年07月15日 01:31, Takashi Iwai wrote:
On Tue, 14 Jul 2015 18:01:48 +0200,
Fuminobu TAKEYAMA wrote:


- Migration from old /etc/X11/xim setup;
we need to keep the setup as much as possible. How can it be done

Honestly, no good idea.
But I know many users use automatic selection of IMF or have only one
IMF on their system.

Right, it's my guess, too. That said, we'd need at most to evaluate
/etc/sysconfig/language:INPUT_METHOD value, but forget about the setup
in ~/.profile. Who managed to set up ~/.profile should be able to
follow such an easy technical change :)

The new script have a chance to be more interactive, which means
it can show its dialog or message to set up IMs after some system changes.
So they should be able to switch to the new launcher and set up IMs smoothly.

One relevant question about the system setup: should we fix to an IM
once when started/used, or keep it dynamically evaluated at every

This question is something like the current window manager selection.
In the former case, we record it at the login. Then, even if a new IM
package is installed later, the same previous IM will be used, no
matter how the default priority is set. The latter case is like the
current implementation, we take whatever the system default regardless
of the previous usage.

- Let's add a description file to each profile directory, e.g. create
a file /usr/lib/input-method/profile.d/XXX/description, so that a
program that selects IM can show the content of each entry more

Sounds good!

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

It should have a black list of DEs that do not support desktop files.
If the current session is one of them, the script in /etc/X11/xinput.rc.d/
can start an IMF in the same way as the current script.

OK, that's also my expectation.

- The ugly g-s-d workaround: can we implement this in a bit smarter
way once when we redesign the framework?

The workaround does not work as expected anymore on 13.2.
(Let's discuss in a new thread)

An idea is to ask users if they use IBus (only on GNOME) or not.


- It would be safer if we can avoid python for select-im...

2, The bin floder have 2 scripts, select-im is written in python,
Yes. Python can be optional on openSUSE, so keeping in bash script
would be the best, IMO.

It is just the first prototype.
I've already rewritten it into a native application.

Then, I want to avoid a complex shell script, which is one of my motivation.

Yeah, it's just an implementation detail we can tackle later.

1, These codes have copyright,
I'm not sure if there will be some trouble to merge into OpenSUSE.

That's normal BSD-3-cause. I think there should be no problem.
Of course, I can change the license if needed.

4, In /misc/ folder, user use an icon to trigger auto select isn't friendly.
I think we will have a GUI program in future, list all IM framework to
allow customer choose 1.
I guess this isn't about icon or menu item to launch by a user
manually but rather an auto-start desktop file.


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

However, we still need a way showing a recommended IMF or combination of IMF
and engines,
which depends on the current locale.

Note that there are (still) input methods that does not depend on
any IMF such as Fcitx nor IBus.

An example is Hime, which is the default IM for zh_TW.
Mozc might become a such type of IM after the IBus support is dropped.

Woo hoo, that's an interesting move...

Freedom sometimes limit smartness...

Yes, as always :)

I thought somehow the things get merged to the common IMF, but it
doesn't look happening so much yet. If so, having a selection
mechanism per locale is still worth, IMO. It makes things slightly
more complex, but not too much. The complexity in the packaging side
can be avoided by providing a helper macro, for example.

5, In /profile.d/ you gracefully write fcitx and ibus scripts here.
but We should remember that there may be other IM frame like: scim, xim ...
Also custemer may remove ibus or fcitx manually.
So these start scripts are suppose to keep in the inputmethod rpms,
On the other hand, The select program is independent and installed by

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:

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



To unsubscribe, e-mail: opensuse-m17n+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-m17n+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups