[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    A Taste of Immodule for Qt
From:       Ken Deeter <ktdeeter () alumni ! princeton ! edu>
Date:       2004-04-28 17:49:14
Message-ID: 20040428104914.6e4c806c.ktdeeter () alumni ! princeton ! edu
[Download RAW message or body]



Introducing Immodule for Qt
---------------------------

We at the JKUG (Japan KDE Users' group http://www.kde.gr.jp) are
writing to announce and to spread the word about an ongoing effort to
improve input method support in the Qt/KDE framework. This message
provides a brief overview of the effort as well as currently available
results. More information can be found at our website.


English documentation:
 http://www.kde.gr.jp/~daisuke/immodule_for_qt/ImmoduleForQtDocs.html

Patch download:
 http://www.kde.gr.jp/~daisuke/immodule_for_qt/patch/

Add on module for UIM input method library:
http://www.kde.gr.jp/~daisuke/immodule_for_qt/pukiwiki/?QUimInputContext


Overview
--------

* What are input methods?

Input methods are specialized software programs that enable users to
input non-alphabet based scripts using an alphabetic keyboard. In the
CJK world, they are absolutely required to be able to input text in a
sane manner using the keyboard.

* History of input methods on Linux

Until recently, the Linux (and UNIX) desktop has standardized
around the XIM (X Input Method) protocol. Most major toolkits (gtk1,
qt2/3, gtk2, etc) support this protocol. XIM has several major
limitations (within the context of desktops) however:

 - it is difficult to use: it requires the setting of several magic
environment variables (LANG, LC_ALL, XMODIFIERS) for proper operation.
It also requires the startup of a XIM server during X session start up
(some xdm's handle this, but most of the time this means users
manually editing~/.xinitrc or similar)

 - inflexible: it has been found that the protocol does not deal well
with UTF-8, making the development multi-lingual input method over XIM
difficult. Also, it has not mechanism for changing input methods on the
fly.

In response to XIM's deficiencies, several other input method libraries
have been developed. UIM is a project hosted by freedesktop.org, which
aims to provide a library of input methods, which can be accessed using
a linkable library, instead of a network/socket protocol. Another major
effort is the IIIMF framework, which aims also to replace XIM, and also
to support run-time switching of input methods and provide input methods
for many languages in one unified package. The creator of the IIIMF
effort is indeed one of original designers of XIM itself, looking to
replace the outdated framework with something modern and useful.

Currently, the only major toolkit in the unix desktop arena with strong
input method support is GTK2 (aside from emacs, if that can be
considered a toolkit). The GTK2 toolkit has an"immodule" framework which
allows third party binary modules to be written to allow support for new
input methods. In GTK2, the current input method for each input widget
can be changed by accessing the context menu using the right mouse
button. Although this functionality is rather basic, it does provide the
ability to use several different input methods to input different
languages into one running instance of a program.

For those unfamiliar with input methods, the ability to switch methods
can be likened to a "keyboard switcher" applet available on most
desktops, which allows users to input different variations of
alphabet-based languages. Although the mechanisms for input methods are
slightly different, the concept is very similar. As many CJK users can
partially understand the other of the CJK languages, the ability to
input characters of those other languages without restarting programs is
very important, especially as more and more of the population of these
countries come online and begin to interact with each other.

* What is Immodule for Qt?

The goal of this project is, as the name states, to provide a
functionality similar to gtk's immodule for the Qt library (and
consequently, all of KDE). It is a patch to Qt that allows developers to
provide dynamically loadable plugins (much like style engines) to
support interactions with new input method libraries and architectures.

We feel that the spread of the great KDE technology is somewhat hampered
in the CJK world by the lack of strong support for input methods in the
Qt library. Current KDE users are patient, but are increasingly drawn
toward the GNOME solution, as the GTK toolkit directly addresses these
problems.

A basic patch with verified functionality is already available (which
applies against qt 3.3.1) It can be found at the link for downloads
listed at the top of this message. Although this patch breaks binary
compatibility with the 3.x series (it does keep API and source
compatibility), we hope it will be considered a strong candidate for
inclusion in Qt4.

* Why are we writing to these lists?

Our main goal is to raise the awareness for this problem, as well as
related internationalization and multilingualization problems in Qt/KDE.
We also notice that the recent news items about Qt4 from Trolltech do
not mention anything about input methods, and so by going through the
Open Source KDE community, we wish to alert Trolltech developers of
these issues.

We feel that addressing this problem is fundamental to furthering KDE's
spread in at minimum, the CJK world (with some ~1.4 billion people). We
would hate to see such a great technology go unused because of a
basic design flaw. Although some major distributions (such as
Turbolinux, Red Flag, Hancom) already use KDE as their default desktop,
we cannot expect this situation to last if the input issues (among
others) are not addressed in Qt.

* Our plans

As our initial feature set has been completed, we are looking for
feedback from both Trolltech (to raise our chances as much as possible
for inclusion in Qt4) as well as from the community. 

* For more information and contact

Contact me at 
     kdeeter at alumni dot princeton dot edu
and I can relay/translate the email to the group or,
     daisuke at kde dot gr dot jp
if you would like to contact the lead developer directly.

Discussion is being held (currently in Japanese) on the Qt-devel mailing
list at kde.gr.jp. More info at the address below:
http://www.kde.gr.jp/ml.php
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]