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 _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
