[immodule-qt] Re: Question about svn trunk

[LiuCougar]

On Tue, 13 Jul 2004 02:46:53 +0900, YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> At Mon, 12 Jul 2004 23:19:18 +0900,
> kaminmat at cc.rim.or.jp wrote:
> >
> > On Monday 12 July 2004 06:41, YamaKen wrote:
> > I am planning to provide API for external IM-switching infrastructure.
> > Why do you think this solution is not good?
> 
> 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?
 
> > It desirable to realize the following function as a error handling.
> > - deletion of QInputContext's instance
> 
> Yes, it is the required function. I had expressed it as "delete
> me message".
> 
> > - prevention of choosing the module in appliation in use
> 
> I can't understand what you mentioned. Please show me a scenario
> as example.
IMO, one example is: a qt-immodule plugin (say scim-qtimm) can only
handle CJK (in fact can also handle some other ones) input methods,
then it makes no sense to display this plugin in a context-menu under
other locales (other then utf-8, of course)
So I think this suggest us to have some properties support in
qt-immodule, such as what languages it can handle etc.

BTW: I do not think a Language() function in inputcontext is a good
practice, maybe we should do it in a more generic way, such as a
generic query API, so we can add/delete properties without breaking BC
or adding new APIs.

> > > Probably you have forgotten the
> > > code. QETWidget::translateKeyEventInternal() uses a static
> > > variable instead of instance variable to store the state as
> > > following, so lastWinId is required to prevent interwidget key
> > > state transition.
> >
> > I understood that the static variable in a method was separately
> > treated for each instance. lastWinId will be required if this understanding
> > is wrong. Please commit the code.
> 
> At least, gcc 3.3.3 showed that my understanding is correct. See
> attached code and following result.
> 
> $ gcc --version
> gcc (GCC) 3.3.3 [FreeBSD] 20031106
> $ ./a.out
> 0xbfbfe7cf: initial
> 0xbfbfe7ce: initial
> 0xbfbfe7cf: a
> 0xbfbfe7ce: a
> 
> But I had recently seen some C++ codes based on your
> understanding. Is it a new C++ feature? Or, is some famous
> (wrong) explanation about it existing?
I stand with Daisuke, but I will verify this later.

Regards,
Cougar