[immodule-qt] introducing QT_IM_SWITCHER environment variable

[Takumi ASAKI]

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.


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.

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

> 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
> 

-- 
  Che Che - Bye Bye
        From: Takumi ASAKI <takumi at asaki.jp>
	URL: http://asaki.jp/