Currently if the GTK_IM_MODULE environment variable is unset, it means that GTK+ "automatically" chooses a suitable immodule based upon the installed software. This means that in FC5 logging into English, SCIM's immodule is loaded into memory despite English having no need for it. This is in conflict with how our desktop environment is configured, with xinput.d where GTK_IM_MODULE is set based upon the login LANG. GTK_IM_MODULE is unset in languages like English which have no need for IM. With GTK+'s current "automatic" behavior, it loads an immodule based upon the installed software. This is bad because both the memory profile of every GTK+ application (e.g. Bug #166041) and runtime behavior (e.g. Bug #167088) are affected by an arbitrary set of installed packages. This leads to unpredictable behavior based upon the precedence of unused and unseen software. This means confusing bug reports and added maintenance burden and wasted time. The simple solution to all of these problems would be to change GTK+ so GTK_IM_MODULE unset means gtk-im-context-simple rather than "automatically choose an arbitrary immodule". This creates perfectly predictable behavior no matter what packages are installed. This also causes NO CHANGE in behavior in our supported configurations of desktop software. There is some disagreement in eng-i18n whether this is the right decision, so I invite them to make counter arguments in this report before any change is made in the gtk2 package.
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.