Re: Extension to XIM support

[Alexander Malmberg]

Kazunobu Kuriyama wrote:
[snip]
> >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?

Regardless of the name, they have to be conscious of XIM specifics to
know which the possible values for the default are.

> I think they prefer shoter names without
> any jargon, though it saves only 3 characters.

OTOH, they should be long enough to give sufficient information about
what they mean. After the (slight) GSFontAntiAlias mess, I've thought
about this, and I've come to the conclusion that if a default only
applies in a certain context (eg. only when using some backends), or if
the interpretation or set of legal values changes with context (again,
different backends...), it should have a name that tells you in which
context it applies.

I think most of the reasons can be seen already with GSFontAntiAlias:

* It's messy. GSFontAntiAlias means different things depending on which
backend you use (and nothing at all on win32, which might confuse
users).

* It makes it harder to switch backends. The value for the old backend
is likely to confuse the new backend and/or the user.

* It makes it hard for external apps to handle. Even thought
GSFontAntiAlias is a boolean in both cases, the default value is
different. You can set GSFontAntiAlias in Preferences, but it thinks
that the default is NO, which is only true for back-xlib.

(In hindsight, I shouldn't have used GSFontAntiAlias in back-art, but it
seemed convenient at the time, and I suppose I should change it.
Unfortunately, there are many other backend specific defaults with
generic names in -back.)

> (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.)

The default is XIM-specific, and this should be reflected in its name
(by including X or XIM or something). _-gui_ is not XIM- or X-specific,
and this should be reflected in its implementation (by not including X-
or XIM-specific code in it).

[snip]
> Do you still think NSInputManager etc should take such responsibility?

Yes. The "proper" (in a *step sense) way of doing this would be to use
NSInputManager, NSTextInput, et al. However, if it is impossible or
prohibitively difficult to make XIM fit into this, a decent solution
would be to add generic hooks to NSTextView. I could add two methods:

-(void) _updateInputMethodWithInsertionPoint: (NSPoint)p;
-(void) _updateInputMethodState;

and call them where necessary. The implementations in the main
NSTextView implementation would be empty, and you could provide the
XIM-specific versions in a category somewhere in back/Source/x11/ (using
internal backend methods on XGServer). Although this would be outside
the normal text input architecture, it would keep the X-specific parts
in the X backend, I don't see any technical reasons why it wouldn't
work, and no other changes would be necessary in -gui so it wouldn't
conflict with anything on other backends.

- Alexander Malmberg