PROPOSAL: restructure the choice of input methods

[Akira TAGOH]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060602/2fac135d/attachment.sig>