[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RFC] Text Input Management System (5)
From: |
Kazunobu Kuriyama |
Subject: |
[RFC] Text Input Management System (5) |
Date: |
Fri, 16 Apr 2004 11:31:19 +0900 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 |
This is a note on the current status of the development.
Kazunobu Kuriyama wrote:
Hi,
I'm now developing a text input management system described in Apple's
document:
http://developer.apple.com/documentation/Cocoa/Conceptual/InputManager/index.html
<snip>
To address these problems, my general idea is to divide the problems
into the
following four phases to conquer them:
(1) Give real implementations to NSInputManager and NSInputServer, and
provide
a replacement of the current input system.
(2) Modify NSApplication and NSResponder in such a way that they
accommodate
the coming input management system. (An input server is designed to be
launched from the main menu of an application. Thus NSApplication is
included. )
I've just finished the phase #2. Contrary to my previous expectation, I
didn't
need to poke at NSApplication. Everything needed is done with
NSInputManager
and the interaction between NSResponder and NSInputManager. The
interaction is
reasonably small; actually, NSResponder uses only two method defined in
NSInputManager in +initialize and -interpretKeyEvents.
Now I think this particular -gui has an almost complete infrastructure which
supports a Cocoa-like text input management system. The only missing factor
is an NSTextView implementation which supports the so-called marked text.
IOW, if you don't care about this factor, the new system already offers
what you expect an text input management system to do. In short, it fully
works for you if you don't need any exotic characters.
Said that, I absolutely need the feature before going to the following
phases:
(3) Write a fully featured input server fulfilling the requests (or
messages
specified by the NSInputServiceProvider protocol) from one or more
text views
conforming to the NSTextInput protocol. Such a server would be a
prototype
of the so-called "platform input server", or language-specific server,
and
encourage developers to write input servers for their own languages.
This would be fairly easy if the feature metioned above were supported...
(4) Write an input server for my own language. Technically, this implies
that getting GNUstep to talk with a conversion server[1] directly,
thereby
eliminating the dependency on the front end program for the X input
method.
I'm now studying a conversion server protocol, called FreeWnn, as it has
been
widely used in UNIX-like environments for a decade and more here in Japan.
Regards,
- Kazunobu Kuriyama