bug-gnustep
[Top][All Lists]
Advanced

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

XIM patch


From: Christian Gillot
Subject: XIM patch
Date: 21 Dec 2001 15:41:15 +0100

Sorry to resend that patch I think the attachment wasn't in the
previous mail.

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.

-- 
Christian Gillot <cgillot@gruposbd.com>
GNU/Linux programmer

Attachment: ChangeLog
Description: Text document

Attachment: xim.patch
Description: Text Data


reply via email to

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