[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extension to XIM support
From: |
Kazunobu Kuriyama |
Subject: |
Re: Extension to XIM support |
Date: |
Sat, 12 Jul 2003 03:36:08 +0900 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.0.0) Gecko/20020614 |
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
- Extension to XIM support, Kazunobu Kuriyama, 2003/07/10
- Re: Extension to XIM support, Adam Fedor, 2003/07/10
- Re: Extension to XIM support, Alexander Malmberg, 2003/07/10
- Re: Extension to XIM support, Kazunobu Kuriyama, 2003/07/11
- Re: Extension to XIM support, Alexander Malmberg, 2003/07/11
- Re: Extension to XIM support,
Kazunobu Kuriyama <=
- Re: Extension to XIM support, Alexander Malmberg, 2003/07/11
- Re: Extension to XIM support, Adam Fedor, 2003/07/11
- Re: Extension to XIM support, Alexander Malmberg, 2003/07/11
- Re: Extension to XIM support, Kazunobu Kuriyama, 2003/07/11
- Re: Extension to XIM support, Kazunobu Kuriyama, 2003/07/11
- Re: Extension to XIM support, Alexander Malmberg, 2003/07/12