[immodule-qt] Re: Question about svn trunk

[YamaKen]

At Wed, 14 Jul 2004 17:19:01 +0100,
liucougar at gmail.com wrote:
> 
> On Tue, 13 Jul 2004 02:46:53 +0900, YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > I don't think that external IM-switching is bad. But I think
> > that GTK+'s context-menu style switching should also be able to
> > be implemented as ordinary IM plugin.
> > #I had misexpressed it in previous mail 
> > What do you think 'API for external IM-switching' as? I think that
> > no additional API is required to communicate with external
> > IM-switching infrastructure. The switcher may be able to be
> > implemented as ordinary IM plugin. Suppose SCIM. Although it
> > only switches between its own IMEngines, all input methods are
> > multiplexed as one plugin. Qt is not aware of the switching.
> Yeap, this is a situation, but there is another one we should
> consider: dynamic switching qt-immodule, such as between uim-qtimm and
> scim-qtimm in the same application? I think qt-immodule infracture
> should support this, won't it?

Hmm... I have to say my opinion more obviously. There are 2
different requirements.

1. the immodule API should allow implementing an IM-switcher as
   ordinary plugin that delegates the switching responsibility
   to external IM-switcher (suppose SCIM's switching behavior)

2. the immodule API should allow implementing an IM-switcher as
   ordinary plugin that switches between qt-immodules (like
   gtkimmulticontext)

I had expressed 1. as 'external IM-switching', and 2. as 'GTK+'s
context-menu style switching', so of course I agree with you.

As I've mentioned the problem in the recent reply for the dead
key issue, the API has to be modified. Daisuke, tell us what is
the 'API for external IM-switching' that you are thinking. I'll
also consider it.

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