[immodule-qt] Slave qt immodule support and dead key issue

[YamaKen]

Hi Cougar, thanks for the review.

At Sat, 17 Jul 2004 16:38:34 +0000,
liucougar at gmail.com wrote:
> My comment about this patch:
> about qinputcontext:
> I think inputMethodName() is no better than the original name(),
> because as you know in uim-qimm, that is input method name, but in
> scim-qtimm, there is only one name "SCIM", so I think a more generic
> name() function is better ;)

You had spotted a good discussion point. I also think
inputMethodName() is a bad temporary name, but the renaming
itself is required because name() is conflicting with
QObject::name().

We should accurately define what is the responsibility of the
QInputContext::inputMethodName(), and rename it appropriately.

There are two different names with different responsibility in
the input method world as below, but I think that the
responsibility of QInputContext::name() was not explained enough
and the name is inappropriate.

- Display name

  The name for endusers appeared in a menu and so on. It should
  be translated according to the locale as i18n string. In our
  implementation, QInputContextPlugin::displayName() is a this
  name.

- Identifier name (canonical name)

  The name to identify and specify input methods for the
  switching mechanism and so on. I think that
  QInputContext::inputMethodName() must be it and has to be
  consistent with QInputContextPlugin::keys(). We should
  explicitly describe this constraint into the document. I also
  think that it should be QCString rather than QString to avoid
  using i18n string for this and confusing this with display
  name.

We have to determine whether following issues are appropriate or
not. Anyone, please tell me your opinion.

- QInputContext::inputMethodName() is a identifier name
- The name has to be consistent with other functions such as
  keys()
- The name for a input method should be consistent with the name
  appeared in other immodule-like frameworks as 'canonical name'
  to help desktop-wide IM-switching
  e.g.) use the single name "uim-anthy" for qt-immodule,
        gtk-immodule and so on for the uim-anthy input method

And we also have to define appropriate function names for each
following domains. I suggest displayName() and identifierName()
from the point of view of roles.

- display name
- identifier name

I also have a question about the names in the IIIMF. IIIMF has
the term 'human readable name' and 'idname'. Does it
corresponding to the two names described as above?

> about multcontext:
> 1. maybe we should take x11FilterEvent into account too, for some
> inputcontext uses it rather than filterEvent (such as the latest
> scim-qtimm ;)

Oops, that's my mistake.

> 2. connect signal imEventGenerated to multicontext signal
> imEventGenerated directly would be better

Regard the implementation as placeholder for future extension or
experiment such as commit string snooping. But your suggestion
is reasonable for acting as ordinary immodule-switcher, so I
will directly connect it by default as you said.

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