Mailinglist Archive: opensuse-m17n (46 mails)

< Previous Next >
Re: [opensuse-m17n] Does our xim process need an update?
On Wed, 15 Jul 2015 14:41:01 +0200,
Qiang Zhao wrote:

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

3, Select the default IM framework base language is useless in my opinion,
So I think select-im only accept an IM name parameter, and set for
current user is enough.
also, no need to divide in locale.d sub-folders. See my previous

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

A related question is whether we should mandate the IM framework for
all locales. If user doesn't need more than XKB, why another layer
should be there to make things complicated?
On the other hand,
We still don't know which customer doesn't need more than XKB.
So I think the better solution is to make an option on
of XKB(No IM Frame work but only XKB).
Please notice that even we choose by locales, it will not always be right.

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

And, last but not least, the case where multiple IM frameworks
coexit: who decide which IM framework to choose?

(BTW, one interesting thought is to start all IM frameworks at the
same time. This works in theory, and even works practically with Qt
that has a IM switcher. GTK has a fixed binding, so it doesn't work
on the fly. If we have a IM switcher on GTK like Qt, we may start
all frameworks no matter whether it's used or not, then let user
choose later.)
It is a really good idea, I considered it in my mind for a long time.
And please notice it brings some new works,
including bug fix, update with SLE, QA... at least.
Many wonderful feature's situation is like that:
Do we have enough people to work on this point in future?

This is no SUSE specific but rather an upstream work, so the question
should be directed to the upstream devs :)

I can imagine that Gtk IM switcher is feasible, but I'm not so certain
whether this would be well received. It's technically interesting,
but it leads to complexity (yeah, yet another layer).

4, In /misc/ folder, user use an icon to trigger auto select isn't
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.


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

< Previous Next >
List Navigation
Follow Ups