[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
XIM patch
From: |
cgillot |
Subject: |
XIM patch |
Date: |
Fri, 21 Dec 2001 15:38:42 +0100 (CET) |
User-agent: |
IMP/PHP IMAP webmail program 2.2.6 |
Hi,
Well, I finally did it. Here is a very first XIM implementation.
It just works for european languages (dead keys/compose).
I've been late making it because I had to learn the OpenStep API
before digging deeper GNUstep. Don't hesitate mailing me if something
is wrong in it. I just would like to stress that it's a first
incomplete implementation but it do works.
> Yes - there are quite a lot of issues with text management in gnustep. :-)
Well the bases are here ;o)
>
> My suggestion is to have a look into
>
> NSInputManager / NSInputServer
>
> in the MacOS-X documentation - because there is were the input managing is
> supposed to be done according to their documentation.
>
> MacOS-X uses a remote InputServer - we should think whether we want to
> have that / whether it can be fit in our environment or not.
>
> The questions we want to ask ourselves are probably -
>
> * what are the advantages of having a remote input server
>
> * what are the disadvantages of having a remote input server
>
> * how would that fit in our environment
>
> I've not yet thought about these issues, so I don't have answers ready.
I read thorougly the XIM documentation and the gtk XIM implementation,
so let me tell what I think.
X make a huge difference between the input server and the client, that
is to say we just need to code the support of XIM by using the client API.
So the remote code will be in the X input server, depending on the client
it could be none (US), integrated in X (european languages) or by an external
programme (typically asian languages). But I think that each GNUstep program
need to use a NSInputServer client of XIM which will fire NSEvent rather
than the actual implementation and will communicate with the GUI to make
it compliant with the user Input Method (i.e. make the text entry that
size, make a status bar for the IM, etc). The issue is that it's very
architecture dependant, so the NSInputServer and maybe parts of NSInputManager
will in xgps/SharedX because it's going to work upong x events, not
NSEvent, is this clear ?
We do not need to follow MacOsX's NSInputManager and especially NSInputServer
because there are partly architecture-specifique, i.e. in that case
MacOSX-centric.
Remember that X let the user choose a different IM for each program.
>
> > And now the questions :
>
> > - Is there anybody working on this right now ?
>
> not really - but I'm probably the one having done more work on keyboard
> input up to now
>
> I might take long to answer because I've my hands in too many things :-)
> please be patient and don't let you down just because I'm sometime slow in
> answering.
That's OK. I think that if it's OK I'm going to continue working on this
if you're ok.
>
> > - Do I need to do a copyright assignment to the FSF ?
>
> Yes
Let me know what I've got to do.
xim.patch
Description: Binary data
ChangeLog
Description: Binary data