[immodule-qt] Re: Question about svn trunk

[YamaKen]

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 think that "Multiplexing IM can be implemented as ordinary IM
> > plugin" is the best way, as I had told you in Feb 2004. 
> 
> I agree with you.
> 
> > But I think that IM-switching _can_ be accomplished by switching
> > QInputContext without external IM-switching
> > infrastructure. 
> 
> Does this mean that IM-switching should be realized by the tool 
> of Qt (like qtconfig)?

No. I supposed a GTK+'s context-menu style switching.

> 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.

> > We should investigate the action based popup menu of Qt4 to know
> > whether pluggable menu is realizable or not.
> 
> Surely, offering API for popup menu may expand the width of the choice
> of application programmers and users. So, I think that providing the 
> pluggable menu of IM-switching as your proposal is a good idea.

Yes, providing alternative ways is better for recent
circumstances.

> Who investigate that?
> If nobody do, I will do it.

Please go ahead. I will go into other parts.

> 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.

> - display of Error message

I think that it is an excessive generalization. Showing error
messages by plugin itself using their own widgets is appropriate
and optimal. Embedding the error message handling into the Qt
library will cause design error and make an infrastructure for
nobody. Not all input methods require error message handling.

> Do you think that implementing these function by the signal is good?
> Or is another method good?

I can't judge it yet. Let's discover what is the requirements.

> > 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?

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpp-static.cpp
Type: application/octet-stream
Size: 363 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/immodule-qt/attachments/20040713/8be7db68/attachment.obj