[immodule-qt] Re: Question about svn trunk
yamaken at bp.iij4u.or.jp
Mon Jul 12 20:46:53 EEST 2004
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
> 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
> - prevention of choosing the module in appliation in use
I can't understand what you mentioned. Please show me a scenario
> - 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
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...
Size: 363 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/immodule-qt/attachments/20040713/8be7db68/attachment.obj
More information about the immodule-qt