8:57 a.m.
Hi folks,
Currently we have supported to choose input methods against
current locale when the desktop is started. however it is a
little complex and some feature was actually
kindless. e.g. it allows people to specify the different
input methods for the different locale though, the input
method which we have used by default, scim has only
supported the input method switching in itself and it is not
controllable from outside scim. There are input methods
that allows to specify which the input method engine would be
used by default though, it makes confusion and may be
incompatible in the future between the input method and
something tools. So I think we need to restructure it for
next release.
My proposal is:
- input methods that has supported the different input method
engines for different languages or has such framework,
only provides the alternatives name, xinput-default.
- single input methods, such as XIM server provides the
alternatives name, xinput-ll_CC for only their supported
locale. i.e. if one supports ja_JP.* locale, it has to
provides xinput-ja_JP.
- $HOME/.xinput.d would be obsoletes. it is maybe
overkill. just a file like .xinputrc would be better.
- one xinput script which is usually put under
/etc/X11/xinit/xinput.d/, invokes the proper XIM server
for people who still wants to use them.
so if one wants to use XIM, symlink it to .xinputrc or
changing with alternatives will do that. it is still
better than current one since XIM server works on only the
exact locale and it will be less trouble.
- xinput.sh reads only xinput-default (and .xinputrc for the
user-specific thing) and stop to find ll_CC things against
current locale. according to the above reasons.
Any comments/objections are welcome.
TIA,
--
Akira TAGOH
3:58 p.m.
On Fri, 02 Jun 2006 22:57:55 +0900, Akira TAGOH wrote:
- one xinput script which is usually put under
/etc/X11/xinit/xinput.d/, invokes the proper XIM server
<..snip..>
better than current one since XIM server works on only the
exact locale and it will be less trouble.
Sounds like a great idea.
- xinput.sh reads only xinput-default (and .xinputrc for the
One question about xinput-default,
currently "scim" is in core and "uim" is in extras, both supports
multiple
languages so I guess you plan to let them supply "xinput-default" and
"xinput-uim" respectively?
10:52 p.m.
Hi,
>>>> On Sat, 03 Jun 2006 04:58:16 +0800,
>>>> "ST" == Scott Tsai <scottt.tw(a)gmail.com> wrote:
ST> One question about xinput-default,
ST> currently "scim" is in core and "uim" is in extras, both
supports multiple
ST> languages so I guess you plan to let them supply "xinput-default" and
ST> "xinput-uim" respectively?
both scim and uim will provides xinput-default which is
managed under alternatives as currently it does for ll_CC
things. So if you want to change the default behavior to
uim for system wide, /usr/sbin/alternatives --config
xinput-default will be the way.
--
Akira TAGOH
10:39 p.m.
On Fri, Jun 02, 2006 at 10:57:55PM +0900, Akira TAGOH wrote:
My proposal is:
- input methods that has supported the different input method
engines for different languages or has such framework,
only provides the alternatives name, xinput-default.
<snip>
- xinput.sh reads only xinput-default (and .xinputrc for the
user-specific thing) and stop to find ll_CC things against
current locale. according to the above reasons.
So, I agree that this makes sense for things like scim and uim;
since they have internal configurations and can work for lots of
different languages (and aren't tied to a particular locale or
language like XIM -- even the XIM implementations for uim and scim
can only work with one language at a time).
If I understand your proposal, this would mean that some default
input method (whether scim or uim) would be started in all locales,
even though that typical don't need it or don't use it currently.
That's actually helpful for people like me who run in en_US locale
but want to use an input method for Japanese or other languages
occasionally. For people who normally don't use input methods at
all, would this cause a problem, or would it be configured so that
the default would be essentially no input method? People who aren't
used to input methods could be very confused if Shift+Space or something
else started turning on an input method.
John Thacker
10:57 p.m.
>>>> On Fri, 2 Jun 2006 23:39:13 -0400,
>>>> "JT" == John Thacker <thacker(a)math.cornell.edu> wrote:
JT> If I understand your proposal, this would mean that some default
JT> input method (whether scim or uim) would be started in all locales,
JT> even though that typical don't need it or don't use it currently.
Yes.
JT> That's actually helpful for people like me who run in en_US locale
JT> but want to use an input method for Japanese or other languages
JT> occasionally. For people who normally don't use input methods at
JT> all, would this cause a problem, or would it be configured so that
JT> the default would be essentially no input method? People who aren't
JT> used to input methods could be very confused if Shift+Space or something
JT> else started turning on an input method.
Good question. I'm planning to provide the input method GUI
configuration tool and with an option like "never use input
methods", to disable the whole input methods for people who
don't want to use input methods at all. but the default
behavior will enables input methods as scim has already done
in rawhide.
Ideally even if it's running by default for all the locales,
any problems shouldn't be happened and if there are, it
should be fixed. also we are trying to improve the
keybinding stuff with having them in each IMEs. as IME
specific hotkey I mean. I hope it would be helpful in that
case. If you have any issues, please file a bug into
bugzilla. we would appreciate your bug report.
Thanks,
--
Akira TAGOH
3:57 a.m.
New subject: [Fedora-i18n-list] PROPOSAL: restructure the choice of input methods
Just a few comments to clarify my understanding of the proposal.
Akira TAGOH wrote:
- input methods that has supported the different input method
engines for different languages or has such framework,
only provides the alternatives name, xinput-default.
Ok, so the main change here is that scim, uim, etc will basically just
need to setup a single alternative rather than one for each
"supported" locale. I understand xinput-default here to mean the
current symlink "/etc/X11/xinit/xinput.d/default ->
/etc/alternatives/xinput-default".
- single input methods, such as XIM server provides the
alternatives name, xinput-ll_CC for only their supported
locale. i.e. if one supports ja_JP.* locale, it has to
provides xinput-ja_JP.
This is unchanged.
- $HOME/.xinput.d would be obsoletes. it is maybe
overkill. just a file like .xinputrc would be better.
I would like to suggest using "/etc/X11/xinit/xinputrc" for the system
file instead of "/etc/X11/xinit/xinput.d/default", since that seems
more consistent and logical IMHO.
- one xinput script which is usually put under
/etc/X11/xinit/xinput.d/, invokes the proper XIM server
for people who still wants to use them.
so if one wants to use XIM, symlink it to .xinputrc or
changing with alternatives will do that. it is still
better than current one since XIM server works on only the
exact locale and it will be less trouble.
So basically the current locale selecting code in xinput.sh will move
to this alternative script for xim client setup. We could also
consider renaming "/etc/X11/xinit/xinput.d/" to say
"/etc/X11/xinit/xim.d/" at the same time: that would avoid confusion
between the old xinput.d system and the new xinputrc system.
- xinput.sh reads only xinput-default (and .xinputrc for the
user-specific thing) and stop to find ll_CC things against
current locale. according to the above reasons.
So xinput.sh would first try "~/.xinputrc" and if that doesn't exist
it would read "/etc/X11/xinit/xinputrc".
Jens
11:55 p.m.
New subject: [Fedora-i18n-list] PROPOSAL: restructure the choice of input methods
>>>> On Mon, 05 Jun 2006 17:57:14 +0900,
>>>> "JP" == Jens Petersen <petersen(a)redhat.com> wrote:
JP> Ok, so the main change here is that scim, uim, etc will basically just
JP> need to setup a single alternative rather than one for each
JP> "supported" locale. I understand xinput-default here to mean the
JP> current symlink "/etc/X11/xinit/xinput.d/default ->
JP> /etc/alternatives/xinput-default".
Yes, that's right.
> - single input methods, such as XIM server provides the
> alternatives name, xinput-ll_CC for only their supported
> locale. i.e. if one supports ja_JP.* locale, it has to
> provides xinput-ja_JP.
JP> This is unchanged.
Yes, it's actually the same thing as what currently they
does. I just explained it to clarify what maintainers needs
to do for them.
> - $HOME/.xinput.d would be obsoletes. it is maybe
> overkill. just a file like .xinputrc would be better.
JP> I would like to suggest using "/etc/X11/xinit/xinputrc" for the system
JP> file instead of "/etc/X11/xinit/xinput.d/default", since that seems
JP> more consistent and logical IMHO.
Well, can you explain more details how it works?
right now all xinput scripts such as scim, uim etc etc is
put under /etc/X11/xinit/xinput.d and symlinks for
alternatives as well. are you suggesting to just replace
/etc/X11/xinit/xinit.d/default to /etc/X11/xinit/xinputrc?
i.e. alternatives --install /etc/X11/xinit/xinputrc
xinput-default /etc/X11/xinit/xinput.d/scim 81?
JP> So basically the current locale selecting code in xinput.sh will move
JP> to this alternative script for xim client setup. We could also
JP> consider renaming "/etc/X11/xinit/xinput.d/" to say
JP> "/etc/X11/xinit/xim.d/" at the same time: that would avoid confusion
JP> between the old xinput.d system and the new xinputrc system.
Sounds good - then where should be xinput scripts put onto?
> - xinput.sh reads only xinput-default (and .xinputrc for the
> user-specific thing) and stop to find ll_CC things against
> current locale. according to the above reasons.
JP> So xinput.sh would first try "~/.xinputrc" and if that doesn't exist
JP> it would read "/etc/X11/xinit/xinputrc".
Yes, what I want to say was that the bahavior is based on
current one and looking ll_CC thins up will be
removed.
--
Akira TAGOH
1:31 a.m.
New subject: [Fedora-i18n-list] PROPOSAL: restructure the choice of input methods
Akira TAGOH wrote:
>>>>> On Mon, 05 Jun 2006 17:57:14 +0900,
>>>>> "JP" == Jens Petersen <petersen(a)redhat.com> wrote:
JP> I would like to suggest using
"/etc/X11/xinit/xinputrc" for the system
JP> file instead of "/etc/X11/xinit/xinput.d/default", since that seems
JP> more consistent and logical IMHO.
Well, can you explain more details how it works?
right now all xinput scripts such as scim, uim etc etc is
put under /etc/X11/xinit/xinput.d and symlinks for
alternatives as well. are you suggesting to just replace
/etc/X11/xinit/xinit.d/default to /etc/X11/xinit/xinputrc?
i.e. alternatives --install /etc/X11/xinit/xinputrc
xinput-default /etc/X11/xinit/xinput.d/scim 81?
Ah, you're right I hadn't thought it through clearly enough.
So we need to keep "/etc/X11/xinit/xinput.d/" as you say,
but I still think it is a good idea to move
"/etc/X11/xinit/xinput.d/default" to "/etc/X11/xinit/xinputrc".
JP> So basically the current locale selecting code in xinput.sh
will move
JP> to this alternative script for xim client setup. We could also
JP> consider renaming "/etc/X11/xinit/xinput.d/" to say
JP> "/etc/X11/xinit/xim.d/" at the same time: that would avoid confusion
JP> between the old xinput.d system and the new xinputrc system.
Sounds good - then where should be xinput scripts put onto?
So then maybe it is better to just keep everything in "xinput.d/" or
rename it to "xinputrc.d/"?
Jens
6527
days inactive
6531
days old
7 comments
4 participants
participants (4)
-
Akira TAGOH -
Jens-Ulrik Petersen -
John Thacker -
Scott Tsai