Re: some misuse in XLC_LOCALE file

Hi,

> > The document should be update. "X Locale Database Definition" in XFree86
> > tarball is far too old. Many new features isn't include. I have read a lot
> > os code, but I'm afraid my poor English make me not the proper one to do
> > this job. And some related code seem not be used, thus the intention is hard
> > to guess.
> 
> I'm not a native English speaker too.  But there is another reason, I don't
> think it would be useful.  You noticed that some code is not used and you want
> to replace API.  Also note that an adding new locale to X11 can't be done
> writing new XLC_LOCALE file only but requires additions into the Xlib code.
> If we even keep the existent API but rewrite it using iconv it can make the
> adding new locale simplier.  But in such case we could change XLCD (and
> XLC_LOCALE) and then describe it.
> 
What inspire me to suggest such a work is the fact that misuses exist widely in XLC_LOCALE files. But I agree with you, this work doesn't worth what it costs. As to the idea of rewrite the xlib using iconv, is there a real working plan, or is it just an idea?

> > More importantly, xlib should up-to-date in i18n area. My idea is to
> > introduce a new lib, replaces a bunch of old xlib APIs. With new APIs,
> > an application can use utf8- or wc- functions, base on Unicode internally,
> > and without creation of XLCD object. While old API and xlib leaves not
> > touched to keep backward compatibility, like Xft did before.
> > 
> > Any comments?
> 
> I agree. :)  Do you have a detailed plan?
> You know the locale depended part of Xlib consists of three relatively
> undepended parts:
> * keyboard input and interaction with IM servers
> * subroutines for a selection conversions (and conversion of resource strings)
> * text output.
> I don't think we need another one API for the text output.
> The second part (text property<->text list conversion) needs only from/to CTEXT
> converter in addition to iconv. (It is needed for the compatibility with 'old'
> applications, new ones should use UTF-8 for a communication.)
> The simplest keyboard input (key to wc or utf8) needs only a table for the 
> 'legacy keysyms' to Unicode conversion.
> Hence there is only IM server interaction part where some new API can be added.
> Are there any other functions that absent now but are worth adding?
> 
I agree with you in the three parts division, and I also agree that XOM part will leave untouched, we have Xft anyway. 

What I wnat to do with the conversion part is to make related functioms get rid of XLCD binding. It's easy to achieve either by using iconv or by reusing code from lcCT.c and lcUTF8.c. From CTEXT conversion has no problem. To CTEXT conversion need charset selection, which can be solve by either always use ISO10646-1 or read preffered charset from localeDB without trigger XLCD object constructed.
What make it difficult is that these functions also are used in xlib. If I implement my ideas in a new library instead of modifying xlib code, I must also provide new version of the caller functions. This make things complex. So rewriting xlib keeping current API maybe is a more reasonable idea.

Input related part is most complicated part. merely considering XIM part, protocol, imdkit and client side library all should be enhanced. But this make things out of control. Changing client side library only and cheating IM server at some point may be a temporary resolution. Maybe IIIMF should became mainstream, but I think more research should be done on this point.
In fact, I want more here. I think three kind of input methods, namely keyboard mapping, composing and IM server, should have a common point to manage. A consistent switch method among different input methods should be offered, like Windows does. I noticed the recent discussion on composing method in this maillist. What Kent Karlsson purposed is obviously coming from Windows. But his suggestion can't be fulfilled within current mechanism. I rember you worked to make keboard mapping and composing be synthesized on X server side some time ago. But I think the right point shoud be on client side. X server does too much on keyboard mapping. Mapping info and group switching process should be put in client side, and be load and set per client. But I am not familiar with these input methods due to my language restriction, so maybe I'm totally wrong here.

In my ideal situation, an application written with new API only (I mean i18n related) will use Unicode internal, and doesn't have XLCD object created. However, old applications work just as they used to be.


> Any comments? :)
:) Your comments are especially important to me, because as far as I know, you are the one understand xlib most thoroughly. So, THANK YOU!
 
Xie Qian
 
Open System and Chinese Information Processing Center,
Institute of Software, Chinese Academy of Sciences,
P.O. Box 8718, Beijing 100080, CHINA