[immodule-qt] introducing QT_IM_SWITCHER environment variable

[YamaKen]

Hi Takumi, thanks for the opinion.

At Fri, 6 Aug 2004 23:48:45 +0900,
takumi at asaki.jp wrote:
> 
> On Tuesday 03 August 2004 14:59, YamaKen wrote:
> 
> > Hi all, I propose a new configuration convention about
> > IM-switching. Please reply about my opinion and attached patch.
> 
> If I want to use QMultiInputContext and XIM, then
> setenv QT_IM_SWITCHER imsw-multi
> setenv QT_IM_MODULE xim
> Maybe OK.
> 
> But if I want to do not use QMultiInputContext and want to use XIM, then
> setenv QT_IM_SWITCHER xim
> Hmm...
> 
> I think
> setenv QT_IM_SWITCHER none
> or
> setenv QT_IM_SWITCHER direct
> and
> setenv QT_IM_MODULE xim
> is smart.

I had once thought exactly same scheme as yours (including the
switcher names), and omitted it to keep technical
simplicity. But I've now agreed with you because my old scheme
will spread misunderstanding about IM-switchers among endusers
although ordinary users will not change QT_IM_SWITCHER
configuration from default imsw-multi.

But there is another important requirement from developer's
viewpoint. We should reject special handling for IM-switchers
such as 'disable IM-switcher if QT_IM_SWITCHER == none' in libqt
to keep technical simplicity (see also my recent 'pluggable
IM-switcher' opinion).

To satisfy these contradictive two requirements, I suggest
following new scheme.

- Introduce 'imsw-none' switcher plugin

- 'imsw-none' reads QT_IM_MODULE or the equivalent of qtrc, and
  create the specified input context using
  QInputContextFactory

- Once the input context has been created, imsw-none does
  nothing further. It only participates with instantiation
  rather than proxing QInputContext like QMultiInputContext

The imsw-none isolates IM-switcher issues from libqt, and it's
benefical for developers as I said in the 'pluggable
IM-switcher' opinion. For example, input method developers may
be agreed with introducing generic environment variable to
specify default input method regardless of GUI-toolkits such as
IM_MODULE. We can easily follow the new convention without
updating libqt itself if imsw-none is adopted. Only updating
imsw-none plugin is required.

Although user and developer requirements can almost be satisfied
with above scheme, a little compromise is required.

Although the variables are configured as follows,

setenv QT_IM_SWITCHER imsw-none
setenv QT_IM_MODULE xim

Following configuration is still also valid and works properly.

setenv QT_IM_SWITCHER xim

It confuses ordinary users. Although ordinary users will not
imagine such configuration, weird users will favor such
configuration and publish their configuration memo to the
world. It will confuse victims that googled with 'QT_IM_MODULE'.

To prevent such unwanted happening, we should restrict the
plugins that can be specified by QT_IM_SWITCHER as real
IM-switchers. It can be actualized by checking whether the
specified plugin has the 'imsw-' prefix.

How do you think about the new scheme?

> And, your patch support QT_IM_* env. and qtrc.
> But I think these are same layer and same scope.
> So them confuse users.
> If you want to introduce env. setting, deleting qtrc support is better I think.

I think that the both two schemes are both compromises and
temporary solution, but they are needed until more
sophisticated solution has been developed.

Although the functionality is equivalent, target user group is
different as 'GUI lovers' and 'text editor lovers' and
'system imtegrators'.

We can reduce the confusion by warning to users on qtconfig if
QT_IM_MODULE is configured.

> But there is one problem, If delete qtrc support.
> How can I get list of InputMethods I can set to QT_IM_* env?

I can't imagine good solution. Any ideas?

Generate the list and save it into a file such as
'inputmethods.dir' may be sufficient. But when should we execute
it? What should executes it?

> > In our current implementation, there is a usability problem. We
> > can configure default IM plugin using QT_IM_MODULE env var (or
> > the equivalent in qtrc), but there is no way to control default
> > IM on QMultiInputContext because it is an ordinary plugin. The
> > user interface is not useful.
> > 
> > application          <- QT_IM_MODULE="multi"
> >     |
> > QMultiInputContext
> >     |
> > QFooInputContext
> > 
> > 
> > To resolve such problem, we can introduce additional
> > configuration variable for QMultiInputContext. The Qt itself is
> > not aware of QT_IM_MODULE_FOR_SWITCHER variable.
> > 
> > application          <- QT_IM_MODULE="multi"
> >     |
> > QMultiInputContext   <- QT_IM_MODULE_FOR_SWITCHER="bar"
> >     |
> > QBarInputContext
> > 
> > 
> > Although the problem itself can be resolved as above,
> > unnecessary confusion is also introduced by the solution. Most
> > users will configure QT_IM_MODULE to choose their own favorite
> > IM because they always configure so in GTK+ environment. They
> > will be confused if the configuration QT_IM_MODULE="bar" makes
> > IM-switching menu vanish.
> > 
> > application          <- QT_IM_MODULE="bar"
> >     |
> > QBarInputContext
> > 
> > 
> > To avoid the confusion, I propose following naming
> > convention. The name QT_IM_SWITCHER is just a trick for users to
> > form appropriate mental model. Qt itself is not treat
> > IM-switchers specially. It is still ordinary IM plugin.
> > 
> > application          <- QT_IM_SWITCHER="multi" (default)
> >     |
> > QMultiInputContext   <- QT_IM_MODULE="bar"
> >     |
> > QBarInputContext
> > 
> > 
> > The convention is upward compatible with GTK+. In GTK+, the
> > equivalent of QMultiInputContext is hardcoded as default and not
> > replaceable. But IM-switcher should be replaceable as I said
> > recently, so I propose the new convention.
> > 
> > application         <- gtk_im_multicontext_new()
> >     |
> > GtkIMMulticontext   <- GTK_IM_MODULE="bar"
> >     |
> > GtkIMBarContext
> > 
> > 
> > To accomplish the new convention, I've renamed the identifier
> > name of QMultiInputContext "multi" as "imsw-multi". The "imsw-"
> > prefix prevents IM-switchers from being listed in popup menu as
> > input method. All other IM-switcher implementation is also
> > expected to follow this "imsw-" convention. I think that it
> > should not be API such as QInputContextPlugin::isIMSwitcher()
> > because Qt API should be isolated from IM-switcher issues.
> > 
> > If a system integrator such as RedHat want to make a specific
> > IM-framework the switcher, the patch offers following
> > configuration.
> > 
> > application          <- QT_IM_SWITCHER="iiimqcf"
> >     |
> > IIIMInputContext
> >     |
> > (IIIMF's own switching framework)

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp