[immodule-qt] Re: Question about svn trunk

[Daisuke Kameda]

On Monday 12 July 2004 06:41, YamaKen wrote:
> I want to know that whether your implementation is obsolete or
> not. Should we cleanly reimplement corresponding one? Or, are
> you planning to import it with some modification?
>
> Please tell me straightforward. I think that a miscommunication
> is lying between you and me.

I thought that the function wasn't needed. But, when having written 
previous mail, I thought over once again, and I judged it was required.
So, I am going to import it, if there is no contrary.

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

I am planning to provide API for external IM-switching infrastructure.
Why do you think this solution is not good?

> Although it is not convenient as GTK+'s way, the
> capability of the API will help implementing flexible
> IM-switching solution.
>
> 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.

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


> > > 2. Are you thinking about IMError as deprecated? Although you
> > >    had told me that "I'm uncertain whether IMError is necessary
> > >    or not", I didn't hear that it is deprecated.
[snip]
> > We should implement the all-purpose function for handling the error
> > which may take place by each module. However, I do not have a good
> > idea now.
[snip]
> At least, signal is better than event at following points.
>
> - straightforward model for programmers
> - no learning cost is required to recognize the error handling
>   process
>
> But I think that using signal is _a_ way to implement the error
> handling. It's still just an idea. Please tell me your
> requirements for the error handling.

It desirable to realize the following function as a error handling.
- deletion of QInputContext's instance
- prevention of choosing the module in appliation in use
- display of Error message

Furthermore, probably it will be more good to be able to use 
respective function independently.

For that purpose, it will be inadequate only to send the "delete me" 
message from QInputContext.

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



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


-- 
Daisuke Kameda <kaminmat at cc.rim.or.jp>