[immodule-qt] Re: Question about svn trunk

[YamaKen]

At Mon, 12 Jul 2004 03:31:40 +0900,
kaminmat at cc.rim.or.jp wrote:
> 
> On Sunday 11 July 2004 01:33, YamaKen wrote:
> > 1. Are following interfaces and implementations deprecated and
> >    discarded? Should we cleanly reimplement corresponding one if
> >    we need?
> >
> >   - QInputContextFactory::createPopupSelectIMMenu()
> >   - QInputContextFactory::displayNames()
> >   - QInputContextFactory::selectIMName()
> >   - QInputContextFactoryInterface::displayName()
> >   - QInputContextPlugin::displayName()
> >   - QInputContextPluginPrivate::displayName()
> >   - QTextEdit::enableIMChange
> >   - QTextEdit::slotChangeInputMethod()
> 
> The string which keys() returns should not consider as the object of 
> internationalization. So, displayName() may be necessity in order to 
> internationalize the display of qtconfig.

I had asked that "why these functions are not
imported". Currently no displayName() function is contained in
the trunk.

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.

> But, I think that other methods are unnecessary. These are used 
> for the display of a menu like immodule of gtk+2.x, and these menu 
> are not convenient in my thought.
> 
> Probably, the function to realize tool for changing IM which is not 
> specializing in neither uim, scim nor IIIMF is needed, rather than this menu.
> 
> What do you think about this point? 

I think that "Multiplexing IM can be implemented as ordinary IM
plugin" is the best way, as I had told you in Feb 2004. So I
think that excluding your experimental implementation is a good
decision.

But I think that IM-switching _can_ be accomplished by switching
QInputContext without external IM-switching
infrastructure. 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.

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

> Error handling is necessary. But, I also think that IMError is 
> not a best method for error handling.
> 
> 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. 

What is the 'all-purpose'? I think that simple "delete me"
message from QInputContext is sufficient.

> Do you think to use signal/slot is a better idea? 

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.

> > 3. Why lastWinId in QETWidget::translateKeyEventInternal() is
> >    discarded? I think that your change involving lastWinId had
> >    made sense.
> 
> When translation of keycode was taken out from QETWidget 
> (into translateKeycode()), I introduced lastWinId. Therefore, 
> it is unnecessary to QETWidget::translateKeyEventInternal(). 

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.

QETWidget::translateKeyEventInternal() {
    ...
    static int directionKeyEvent = 0;
    ...
}

I have tested the effect about lastWinId.

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