[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