Re: 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: [email protected]
To contact the owner, e-mail: [email protected]