[immodule-qt] a environment variable to control the module

[YamaKen]

At Tue, 20 Jul 2004 01:18:12 +0900,
kaminmat at cc.rim.or.jp wrote:
> 
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > But, I also approve of the idea that it becomes the origin 
> > > of confusion and trap. And, I think that introduction of environment 
> > > variable named QT_IM_MODULE also become the origin of confusion, 
> > > since it increases the contents to set up.
> > > 
> > > It is the better solution for users to prepare a setting tool which 
> > > performs both the writing to qtrc and a setup of GTK_IM_MODULE.
> > 
> > I can't agree with you, especially reusing GTK_IM_MODULE for the
> > immodule for Qt. Ordinary users will not recognize that
> > GTK_IM_MODULE is affecting the immodule for Qt. It will
> > introduce considerable confusion quite bigger than
> > QT_IM_MODULE. You should consider the power of names.
> 
> No. My opinion is that it should not neither reuse GTK_IM_MODULE in 
> Qt, nor introduce QT_IM_MODULE, since it increases the configuration.
> I can't think good solution adding an environment variable, either.

Ah, now I've understood your opinion. Your 'setting tool which
performs both the writing to qtrc and a setup of GTK_IM_MODULE'
is standing for 'global IM manager that configurates all input
method frameworks and immodules' rather than 'local
configuration tool for Qt', isn't it? Yes, it may be a solution
for endusers, but we should consider automated configuration.

In your opinion, we should also develop a command-line qtrc
configurator to automate immodule specification, such as
following. This is required for integrated IM configuration
system such as in some Linux distributions.

  # qt-set-immodule $USER uim-anthy

But it costs learning and boring work for all qt-set-immodule
users. Considerable time and money will be lost in our input
method world, system integrators, and of course endusers. So I
prefer QT_IM_MODULE, although it is not the best solution.

In your opinion, these costs will come.

1. Users have to find existence of qt-set-immodule

2. Users have to learn how qt-set-immodule works, especially
   participating with multiuser

3. Sometimes users have to remind how qt-set-immodule works

4. Users have to resolve consistency between GTK_IM_MODULE. They
   differs in "when it takes effect" and "what processes will
   take effect". This will be traps.

5. We have to maintain and support qt-set-immodule. Don't think
   it easy


In contrast, QT_IM_MODULE will cost less.

1. Users have to find existence of QT_IM_MODULE, but it will
   easily accomplished by some users who know GTK_IM_MODULE

2. Users have to learn little how QT_IM_MODULE works because it
   is based on familiar environment variable mechanism, and
   existence of GTK_IM_MODULE helps understanding for some users
   who know it

3. Concurrent existence of qtrc and QT_IM_MODULE will be a trap
   or confusion, but it can be reduced if qtconfig aware of
   QT_IM_MODULE and warns to user


Of course we should also actualize global IM configuration (and
switching) mechanism regardless of IM framework as best
solution. I believe that it will come.

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