Mailinglist Archive: opensuse-m17n (46 mails)

< Previous Next >
Re: [opensuse-m17n] Does our xim process need an update?
On Tue, 14 Jul 2015 07:44:10 +0200,
Qiang Zhao wrote:

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.

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

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.

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.


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?


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.


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

< Previous Next >
List Navigation
Follow Ups