[immodule-qt] Surrounding text

[Anuradha Ratnaweera]

Seems as this mail hasn't got to the list, so forwarding again.

---------- Forwarded message ----------

On Tue, 7 Sep 2004 00:03:41 +0900, Daisuke Kameda <kaminmat at cc.rim.or.jp> wrote:
> >
> > What's the status of surrounding text support in the QT 3 patches?
>
> We want to support surrounding text. But nothing is implemented yet.
> And, Although based on the quantity of changes, probably it will be
> introduced in Qt4 or after it.

If we are interested in implementing it (not necessarily commiting to
QT proper) hope you guys will help us getting in to the world of
qt-immodules!  (I am sure you don't have all the time in the world,
but an occational tip or an anwer will be sufficient ;-))

> By the way, I have almost no knowledge about surrounding text.
> So, I want to ask you about the following question.
>
> - Are there any good material about surrounding text?
>
> - Does the code about surrounding text implemented in gtk have
>   sufficient function?

Let me answer the both question in one:  The only good material about
surrounding text we found is in GTK.  I think XIM also has something
like that, but we never could figure out how.  (Yes, I have looked at
IMDKIT).

Surrounding text in gtk has [at least] two functions.
gtk_im_context_get_surrounding() gets the surrounding text and the
present location of the `cursor' in that text, and
gtk_im_context_delete_surrounding() which allows deleting characters
(not bytes) around the cursor.  This is sufficiant to do what we need
to do.

It would have been better if the former function accepted a "max
offset" kind of parameters, because we don't need all the characters
in the surrounding.

> - Which country needs surrounding text support?

We are adding Sinhala language support.  Sinhala is the main language
used in Sri Lanka.  Our project page is http://sinhala.linux.lk .
Surrounding text is necessary to implement the traditional Wijesekara
Keyboard and the new national standard being developed based on it.
We also have a transliterated keymap (already implemented for GTK)
which again produces different characters based on context.

Of course we _could_ create a keymap, but according to our experience
and user feedback, usability of a context sensitive input method is
far far superior.  The main reason is, characters, keystrokes, and
visual glyphs don't have a one to one relationship.

Thanks.

        Anuradha

--

http://www.linux.lk/~anuradha/