Howdy, > > > 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. > > I don't see how lcCT.c and lcUTF8.c could help here. The lcCT.c functions > are very oriented to existent XLCD data and it has unplesant restriction. > It is able to convert CTEXT to multibyte only if charset used in CTEXT presents > in the current locale XLCD. If there are two application using Cyrillic but > on of them uses 'koi8' whereas the another one uses 'microsoft-cp1251' for > lcCT it means they are talking on absolutely different languages. > The lcUTF8.c module actually is iconv but with reduced set of supported > encodings. > That's what I mean. You can either use iconv, or you can use the code in lcCT.c and lcUTF8.c to do what iconv does.
> > > From CTEXT conversion has no problem. > > To CTEXT conversion need charset selection, which can be solve by either > > always use ISO10646-1 > I don't think it is a way. If an application is Unicode-aware it should use > UTF8_STRING for an inter-client communication. If some application doesn't > know UTF8_STRING it is more likely it doesn't accept ISO10646 encapsulated > into CTEXT. Yes, you are right. Using ISO10646-1 charset isn't a acceptible way. I'm affected by some UTF-8 and GB18030 locale, which has ISO10646-1 defined in XLC_LOCALE file. > > > or read preffered charset from localeDB without > > trigger XLCD object constructed. > > Right. But somewhere we have to have such preffered charsets list per locale. > > > 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. > > Agree. > > > 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 never use complex input methods in Windows. Where can I read about them or > what I have to install on Windows box to see this 'consistent switch method'? You can get some information through MSDN. Here is a URL that you can follow the links: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/keyboardinputreference/keyboardinputfunctions/loadkeyboardlayout.asp. More details about Windows IME development can be find in DDK document, but I don't think you will be interested in this. :) To use IME in Windows, you must enable east asian languange support at first. Then you can install some IME. All these can be done through "Locale Setting" in "Control Panel". I'm not so sure about the name, because I only use Chinese version Windows. > > > 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. > > No. Probably you mean I said somewhere that it would be good if Compose rules > were a part of a keyboard map and be kept on a server with other XKB tables. :) > But I didn't mean all mapping and composing should be performed on the server > side. And didn't work on it because it require protocol changes that I don't > dare to do yet. > > > 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. > > What do you mean saying "too much"? Now the mapping itself is performed on I mean by default, every client will get the map from server. And server also is responsible to manage the map change. But as you describes later, in theory any application is free to use any other symbols map obtained from any other source. That's what I want. I think a client should get the map directly, according to certain client-side configuration. > the client side, let alone the composing. The server sends notifications > (events) about key press/release but reports a keycode (scan-code) and a state > of modifiers only but not a keysyms or Unicode chars as the mapping result. > The symbols map kept in the server is not used by the server itself but an > application can obtain it from such 'centralized repository'. In theory any > application is free to use any other symbols map obtained from any other > source. But Xlib doesn't provide an API for it. It silently loads the map > from the server at the first call of XLookupString. And what is worse is that > if some application wants another symbols map there is not way exept to load > new map into the server and all other applications get a notification and > reload own maps too. > > And anyway the side (client or server) where the mapping is processed is > a detail of implementation only, that affects protocol but not an API. > The more important thing is what we want from this API. I guess you want > a flexibility that allows different applications have different symbols maps > and use different 'input language engines'. But if a server could keep as > many different maps as needed, remember what map for what client connection > or window is used and switch them internaly with a focus changes, I think it > is not worse than the client side mapping. > > And don't forget about an opposite side. Many people would like to choose > a language (or a country) once at the system installation and never think > about different keymaps, locales, etc. even if they run client applications > from different machines. I remember someone complained that when he run > clients from other computers they use the same keymap but the compose rules > are different or even don't work for some clients. I suppose it is a serious > reson to have a 'centralized repository' for keymaps and compose rules (and > IMEs if it's possible). On the other hand it doesn't mean applications should > not be able to load keymaps or connect IMEs from other sources. > My idea may be controversial, but I think it worth a try. I will do some programming work to see if it is practical. > As for group switching I think there are differrent opinions here too. I wrote > a small utility that is a keyboard group switcher and indicator. One of its > main features is that it can remember an XKB group for each window separately > and change them automaticaly with a focus moving. This feature is switched > on by default. But I had questions from some users how to switch it off > because they don't like to remember the group in each window but easy > remember what is the current 'global' group state and want a simple indicator > only. :) > > > 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. > > As I said if a group of applications uses Unicode internaly, UTF8_STRING for > a communication, Xft for output and don't use complex IM methods (servers) > they don't need any additional i18n API (except, maybe, keysym to UCS table). > Xie Qian Open System and Chinese Information Processing Center, Institute of Software, Chinese Academy of Sciences, P.O. Box 8718, Beijing 100080, CHINA _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
