Bug 167090

Created attachment 118242 [details]
gtk+-2.8.3-immodule-unset-disable.patch

Proposed patch to solve this problem.  Read this file for a better description
of the problem than what is written above.

The removed code in this patch attempted to select the "best" immodule from the
installed software.  This has always been unreliable as it can very easily make
the wrong choice.  The new proposed behavior of this patch forces the
environment to define an explicit choice of immodule name.  This way behavior
is always predictable and unaffected by arbitrary installed software.

Owen, do you have any comment on this ?

The patch is wrong. If we are installing a SCIM input module that claims
to be the preferred input module for English, and GTK+ picks it when
given no other input, than that is correct behavior.

The auto-pick behavior in GTK+ is used for things like choosing the right
behavior for DEAD_ACUTE + C, and cannot  be removed.

If both im-cedilla and scim-tables properly support "fr", then you have
unpredictable and difficult to support behavior because the immodule
auto-choosing code is naive.  It was written under the mistaken assumption that
you would have only one immodule per language installed, which is not the case
now with modern IM frameworks.  In cases where multiple immodules support the
same language, it relies on the arbitrary order within the gtk.immodules cache
which is *BAD*.

The only predictable behavior that is unaffected by the set of installed
software is if the environment defines an explicit GTK_IM_MODULE.  This is
already done for CJKI languages.  All other undefined languages with this patch
would default to gtk-im-context-simple.  If another language needs a specific
immodule, then it should use xinput.d like CJKI for an explicitly choice.

Either this... or the auto-selection code of gtk2 should be rewritten to become
fully predictable.

(Please hold off on closing this, this definitely requires much more research.)

Well, I basically personally think that using gtk-im-context-simple when
GTK_IM_MODULE is unset, is a little rough. I also doubt this way if acceptable
for upstream.  However the essential problem here is that GTK+ doesn't consider
the use of multiple immodules supported the same language at all. I agreed with
Warren at this point. if the auto-pick behavior is the right way to do, GTK+
should provides the way of configuring the priority of immodule.  Owen, although
you disagreed with Nakai's point that is modifying gtk.immodules itself to
change the order of immodule before, I suppose the only way of fixing the kind
of this problem is to have another file to keep which immodule is prior than
others.  What do you think?
IMHO this problem has to be fixed because GTK+ allows to get the kind of
immodules installed and you can't assume that no duplicated immodules supported
the same languages.

If there are multiple immodules for the same language installed, there has
to be config input from the environment, whether from GTK_IM_MODULE or
from an XSETTING (not currently possible, but it should be)

Trying to keep gtk.immodules in a certain order is a very fragile and
complicated way of "configuration".

Since we set GTK_IM_MODULE for CJK languages, I don't see why we couldn't
set it for latin languages as well, though you'd have to duplicate the 
imcedilla logic.

If setting GTK_IM_MODULE will be the only predictable method of setting immodule
on a per-language basis, then why not also include the proposed patch?

Is it possible for an immodule to dynamically generate its list of supported
languages?  AFAICT it is not possible without changing the current way that gtk+
interfaces immodules.  If this is the case, then this list of supported
languages is unsuitable to modern IM frameworks like IIIIMF, SCIM, or UIM which
can support arbitrary languages based upon the prescence of plugin engines or
table definitions.

This potentially further supports the theory that gtk+'s immodule auto-selection
code has been well intentioned but is fatally flawed.  This then gives us with
two options:

1. Rewrite it and introduce lots of complexity.
2. Remove it and rely on the existing simple system of language-specific
symlinks, xinput.d, and alternatives.  I am working toward making this into an
upstream standard between the different IM projects.

After further discussion in IRC with Owen, we came to a few agreements.  For all
languages that need an immodule, we will use xinput.d to explicitly set that
default in order to guarantee predictable behavior.  This includes the languages
that require dead key input (e.g. im-cedilla) and all of the more complex IM
languages.

This however does not mean that the flawed and unpredictable auto-immodule
selection code will be removed from gtk2.  That code does the "right thing" only
in minimal installs using simple immodules like im-cedilla.  Modern IM
frameworks like iiimf, scim, or uim have needs beyond the original design of the
auto-immodule selection making it completely unsafe to be relied upon.  The
decision was made to completely remove all languages from those immodules for
several reasons including:
1) Ensure that they wont conflict with the simple auto-immodule cases
2) Any static list of supported languages would be inaccurate
3) They aren't needed due to xinput.d assignments

I think it would be safe to use these rules in all future packages:
- Keep language lists in simple immodules provided by gtk2.
- Remove all language lists from other immodules.

Steps Needed
============
1) Remove lang lists from complex immodules (DONE scim-1.4.2-2)
2) Define xinput.d definitions for languages of im-cedilla and other simple
immodules.  These belong in the gtk2 package along with those other immodules. 
We can test these on the side until we know they are working properly before
adding them to gtk2.  alternatives will be used here like all existing xinput.d
languages in order to allow a French user for example to change their
environment to SCIM on a global basis.
3) For the case where an im-cedilla user like French uses SCIM, we must be sure
that disabled SCIM allows input of dead keys.  This should be opened into a new bug.

Warren, will you provide the xinput.d definitions ?

We're not doing SCIM anymore for FC5, moving off blocker list.

Ray was confused about the status of SCIM, disregard the previous message.

Assigning this to me, it is waiting on me to provide the framework.

I guess this doesn't really need to be done anymore.  I only need to be sure
that Bug #169975 SCIM Euro Keyboard fallback works properly.