[immodule-qt] introducing QT_IM_SWITCHER environment variable

YamaKen yamaken at bp.iij4u.or.jp
Mon Aug 9 11:53:26 EEST 2004


At Sat, 07 Aug 2004 16:57:45 +0900,
kaminmat at cc.rim.or.jp wrote:
> 
> Daisuke Kameda <kaminmat at cc.rim.or.jp> wrote:
> 
> > I think that the idea which introduce an environment variable is interesting.
> > 
> > But, probably, "Qt API should be isolated from IM-switcher issues" 
> > contradict "introducing pluggable popup menu". Moreover, I think 
> > that this idea confuses users.
> > 
> > Although it is not the fully considered idea, I think it good to introduce 
> > the method not isIMSwitcher() but hasIMSwitcher(). Then, it could also 
> > clearly show that "Qt API should be isolated from IM-switcher issues" and 
> > we should introduce "pluggable popup menu" for developers' convenience.
> 
> I have misunderstood. I thought that QT_IM_SWITCHER and 
> DefaultInputMethodSwitcher of qtconfig is not setted in the default.
> I understand that DefaultInputMethodSwitcher was surely set. Is it right?

Yes. If neither QT_IM_SWITCHER nor DefaultInputMethodSwitcher is
configured, QApplication::defaultIM fallbacks to
"imsw-multi". if imsw-multi plugin is accidentially absent,
simply first input method will be used.

> I think that the idea which introduces QT_IM_SWITCHER and 
> DefaultInputMethodSwitcher is good. But, I want to hear how 
> DefaultInputMethodSwitcher will be setted up by qtconfig. 
> For example, can arbitrary input method be specified?

You should mind the 'imsw-' naming convention. Only real
IM-switcher can be listed in qtconfig.

But I don't think that DefaultInputMethodSwitcher should not be
configurable in qtconfig for now because there is no useful
alternative for endusers.

> And, it will be necessary to also take Takumi's opinion into consideration.

See also my response to him.

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



More information about the immodule-qt mailing list