bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extension to XIM support


From: Kazunobu Kuriyama
Subject: Re: Extension to XIM support
Date: Fri, 11 Jul 2003 17:18:34 +0900
User-agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.0.0) Gecko/20020614

Alexander Malmberg wrote:

> Kazunobu Kuriyama wrote:
> [snip]
>
>> Because off-the-spot and over-the-spot need to interact with a text
>> drawing
>> object, I have to put some code in -gui.
>
>
> This sound useful, but I think you've added this code in the wrong
> place, which is bad (it can only be used from NSTextView,

For off-the-spot and over-the-spot, you have to tell the input method in
use where it should display two windows; these two windows are provided
to the application  by the input method independently of GNUstep.  One
window is called status area, and the rest preedit area.  Usually, those
two windows look like:

off-the-spot
------------
 +----------------------------------------+
 |                                        | Text Drawing Object
 |      |                                 |
 |      cursor                            |
 |                                        |
 |                                        |
 |----------------------------------------+
 |Status Area | Preedit Area              |
 +----------------------------------------+

N.B. The status area is just like the Emacs editor's mode line.
N.B. In the preedit area, characters under conversion are displayed.


over-the-spot
-------------
 +----------------------------------------+
 |                                        | Text Drawing Object
 |      |Preedit Area|                    |
 |      cursor                            |
 |                                        |
 |                                        |
 |----------------------------------------+
 |Status Area                             |
 +----------------------------------------+

N.B. The status area is just like the Emacs editor's mode line.
N.B. In over-the-spot, The preedit area emerges at the insertion point.

To implement those two styles, you need to know:

(1) The position (relative to the screen) and the size of the text
    drawing object.
(2) The insertion point (relative to screen). (for over-the-spot only)

The necessity of knowing the coordinates relative to the screen is
because, as mentioned above, the windows for the areas have nothing
to do with  GNUstep GUI's window hierarchy, i.e., they are independent
of the GNUstep coodinates system.

At present, I have no idea in getting these values from objects other
than NSTextView.

> it adds
> backend-specific code to -gui, and it doesn't fit in the documented
> input architecture).

In -gui, I don't directly call any method defined in -back.  When I need
a function which is provided by such methods, I always make use of it
through the interfaces newly defined for this purpose:

   NSTextView
<- GSDisplayServer (InputMethod)
<- XGServer (InputMethod)
<- XIMInputServer (InputMethod)

If this violates 'the documented input architecture', could you tell me
which document it that?  I'll read it to correct the implementation.

> Text input (in NSTextView, but potentially also in
> other classes) works by using NSInputManager and the NSTextInput
> protocol, so I think what you should do is implement this in
> NSInputManager. Depending on how extensively you need to change it, it
> might be necessary to implement part of it in the backend.

Even in the extended XIM, text input itself is always done through
-back.  So I think this requirement is implicitly fulfilled. I gurantee
that the extended XIM writes nothing directly to the GUI through my code.

>
> Note that the marked text methods in NSTextInput aren't implemented in
> NSTextView yet. If you need them, tell me and I'll hurry up and
> implement the necessary parts in the text system (can be done easily but
> a bit ugly using copy&paste).
>
Thank you for your kind offer. But you don't need to hurry up as I'm not
sure if I need it right now.

My comments above never claim that the current implementation is the best of
bests. So I truly welcome further suggestion or comment.

- KK








reply via email to

[Prev in Thread] Current Thread [Next in Thread]