Re: Extension to XIM support

[Kazunobu Kuriyama]

Alexander Malmberg wrote:

Before making final decision to modify the code, I'd like ask you some 
points
to confirm.

> Kazunobu Kuriyama wrote:
>
> > Alexander Malmberg wrote:
> >
> > > Adam Fedor wrote:
> [snip]
>
> > > Since the default (or at least its value) is effectively back-xlib
> > > specific, I'd suggest reflecting this in the name, eg.
> > > GSXIMInputMethodStyle.
> > What if the extended XIM also works fine for back-art?
>
> In that case, replace back-xlib with "back-x11". :) It'd still be X- and
> XIM-specific, though, so I think my comment still applies.
I've already finished modifying that part of the code, which now uses a
tentative default name.  Once the name is given, I can change it in a few
seconds. So I'm not reluctant to change it, but...  

Is it necessary even for end-users to be conscious of something specific
to the implementation behind them?  I think they prefer shoter names without
any jargon, though it saves only 3 characters.

(I'm confused a little bit because you suggest that XIM should be used
for the user default name while its related concepts should be avoided
in the implementation.)

> Although this hides the implementation, there are many implementation
> details and XIM-specific concepts in the interfaces (eg. the strings
> returned by -inputMethodStyle, or the "preedit" and "status" areas). I'm
> not familiar with input methods on different platforms, so I don't know
> if these concepts are commonly used. 

I can't design a perfect interface till I've experienced enough; I think
we can't make any conclusive decision till someone offers patches that
support IME (Windows' counterpart of XIM) or Mac's counterpart.  I think
it's not too late to reconsider it till then.  Moreover, because the usage
of input methods is very limited, I hardly imagine lack of generality
causes any devastating impact on the other part of GNUstep.

Implemation details---I have no idea other than using some compilation
swiches.

> However, I can see that if you use
> the standard OPENSTEP
> NSInputManager/NSInputServer/NSInputServiceProvider for input
> management, they wouldn't be appropriate.

Input methods don't do text input by themselves.  They merely passes
their output to the internal of GNUstep through Xutf8lookupString() or
XmbLookupString().  They don't interact directly with NSInputManager etc
and vice versa.

What input methods expect -gui to do is to provide some geometrical data
to them so that they can display the status and preedit areas properly.
I feel this is irrelevant to text input.

Do you still think NSInputManager etc should take such responsibility?

- KK