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
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?
Hi,
On Sat, 03 Jun 2006 04:58:16 +0800, "ST" == Scott Tsai scottt.tw@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
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
On Fri, 2 Jun 2006 23:39:13 -0400, "JT" == John Thacker thacker@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
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
On Mon, 05 Jun 2006 17:57:14 +0900, "JP" == Jens Petersen petersen@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
Akira TAGOH wrote:
On Mon, 05 Jun 2006 17:57:14 +0900, "JP" == Jens Petersen petersen@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
-
Akira TAGOH -
Jens-Ulrik Petersen -
John Thacker -
Scott Tsai