[immodule-qt] Pluggable IM-switcher (Re: Introducing pluggable popup menu)
YamaKen
yamaken at bp.iij4u.or.jp
Sun Aug 8 15:56:18 EEST 2004
Hi Lars,
At Fri, 6 Aug 2004 10:31:12 +0200,
lars at trolltech.com wrote:
>
> On Friday 06 August 2004 00:56, YamaKen wrote:
> > At Thu, 5 Aug 2004 13:23:07 +0200,
> > lars at trolltech.com wrote:
> > Yes, single QAction could be useful for some input methods. We
> > should think it deeper. But I think that current implementation
> > that provides conservative popup menus is sufficient for
> > existing input methods. So I suggest following plan.
> >
> > - Use current implementation for Qt3
> > - Redesign it from scratch for Qt4 based on its new features
>
> In Qt 4 the simplest way would be probably to have a method that returns a
> list of QActions. Like that you can add a whole menu tree (as Qt 4 actions
> can have a menu themselves). The other advantage is that you can add the
> actions to other places as menus as well (e.g. to a specialized tool bar).
>
> So how about
>
> virtual QList<QAction *> actions() const;
>
> for QInputContext in Qt 4?
It seems good enough.
Oops, I'd forgotten or didn't see the design of new QAction well
because I was being sticked to provice popup menu.
> > > Another question I have is about QMultiInputContext. Why do we need this
> > > class at all? Wouldn't it be better to build the support for IM switching
> > > directly into Qt?
> >
> > No. We don't need QMultiInputContext or any other switching
> > support in any Qt part. So I had removed the QMultiInputContext
> > dependency from QLineEdit and QTextEdit. See again my previous
> > patch.
> >
> > I had already removed any other QMultiInputContext dependency
> > from Qt in yesterday morning. See following
> > ChangeLog. QMultiInputContext had reorganized as ordinary IM
> > plugin.
>
> I know. But now QMultiInputContext is an IM plugin that loads the other
> plugins and forwards things to them. What's the advantage of this design over
> a design where we move the switching code directly into Qt 4?
There are 5 reasons I'm considering.
1. to make whole IM-switching facility replaceable to follow new
technologies and specifications
2. to make whole IM-switching facility replaceable to follow
unknown requirements about switching policy
3. to make whole IM-switching facility replaceable in accordance
with a system integrator's own integration policy
4. to isolate IM-switching codes into a immodule plugin to keep
simplicity, portability and maintainability of the immodule
code in libqt
5. to make IM-switching facility portable for other than X11
platform
Let's look into the reasons one by one.
1. to make whole IM-switching facility replaceable to follow new
technologies and specifications
There are no standard global IM-switching framework that
switches all input contexts on a desktop regardless of
GUI-toolkits yet, but it's going to be established. So we should
support it in future.
Although it can be implemented by XChangeProperty as you said,
it's an insufficient solution for us (IIIMF, SCIM, and uim
developers) because it's a X dependent solution. We want it to
be portable for terminal apps, embedded environments, Windows,
Mac OS X, and so on.
Global IM-switching semantics and specification have to be
carefully defined and not so easy. It involves various issues
such as identifier name canonicalization, lightweight and highly
portable IPC protocol for switching message, design consistency
against existing IM-frameworks such as IIIMF, SCIM, and uim.
In addition, the release cycle of Qt will not match the
development cycle of the new IM-switching facility. We will
prefer timely release of corresponding switcher plugin for Qt.
These requirements make pluggable IM-switching reasonable.
2. to make whole IM-switching facility replaceable to follow
unknown requirements about switching policy
We still don't know all requirements about IM-switching. For
example, the requirements for multilingual applications are not
well defined. Suppose an IRC app connecting to a French channel
and a Japanese channel simultaneously. The user will use
QSimpleInputContext for the French channel and a Japanese input
method for the Japanese channel. In such case, a global
IM-switching message will replace both input context of both
channel with new contexts of single input method unnecessarily.
#The use case had been defined by someone in a discussion in
#Japanese in months ago. Sorry, I've forgotten who said it.
The global IM-switching message should be ignored or accepted
appropriately in the case, but we still don't know what is
appropriate.
Pluggable IM-switcher can be updated to behave appropriately
once the requirements have been defined well.
3. to make whole IM-switching facility replaceable in accordance
with a system integrator's own integration policy
Both IIIMF and SCIM have its own IM-switching framework (and uim
is going to provide it), and some system integrator such as
RedHat want to make a specific IM-framework the global switcher
to provide consistent input method UI over the desktop for
users.
In the case, the system integrator wants to disable toolkit's
own local IM-switching facility such as the popup menu of
QMultiInputContext or the equivalent in GTK+.
To meet these requirements, pluggable IM-switcher is the
simplest solution.
4. to isolate IM-switching codes into a immodule plugin to keep
simplicity, portability and maintainability of the immodule
code in libqt
If we hardcode IM-switching process into libqt, it brakes
platform independency and introduces unnecessary porting and
maintaining cost.
For example, suppose Qt/Embedded. Qt/Embedded 2.3.4 or later has
another input method API named QWSInputMethod. Although it's
similar to our QInputContext in several aspect (I had make it
more closer to QWSInputMethod intentionally), Qt/Embedded has
completely different design about input method.
Qt/Embedded had adopted a client-server design for complex and
heavyweight input methods to reduce resource requirements. It's
reasonable design for embedded platforms. All input contexts
(QWSInputMethod instances) are generated in the server process
of Trolltech's own Q Window System. The QWSInputMethod instances
communicate with applications in another process via QWS
protocol over a socket. Since QApplication of Qt/Embedded
translates some QWS protocol events into standard QIMEvent, so
applications can be portable between Qt/Embedded and others.
QIMEvent over IPC
QWSServer ---> applications
|
QWSInputMethod
I strongly want to make Qt4/Embedded compatible with Qt4/X11
about immodule (in accordance with client-server input method
design of Qt/Embedded), so the consistency between both
platforms about immodule is important. If we have decided to
hardcode IM-switcher functionality into libqt, the code
fragments pollute QApplication in X11 and QWSServer in Embedded
in another way. Such code fragments increase the differences
between platforms and cost us careful maintainance of libqt.
Pluggable IM-switcher simplifies the differences between
platforms in libqt.
5. to make IM-switching facility portable for other than X11
platform
I had introduce pluggable popup menu to unify IM-switching menu
and so on between X11 and Embedded. Although it will differently
added to context-menu of text widgets in X11 and IM-chooser of
taskbar in Qtopia (that runs on the server process), the
switcher implementation can be shared between platforms.
We can share IM-switcher implementations between platforms if
the pluggable IM-switcher has been adopted.
I'm not saying that standard IM-switcher along with official Qt
release is not important. The standard imsw-multi switcher
should be useful as default, and should be replaced with
advanced one once it appeared.
-------------------------------
YamaKen yamaken at bp.iij4u.or.jp
More information about the immodule-qt
mailing list