Mailinglist Archive: opensuse-m17n (46 mails)

< Previous Next >
Re: [opensuse-m17n] Does our xim process need an update?
>> 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.

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

On 2015年07月15日 22:12, Takashi Iwai wrote:
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 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?
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.

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

< Previous Next >
List Navigation
Follow Ups