> > > An ideal solution would be to integrate compose rules into XKB (or core > > > protocols) maps but it needs changes in the protocol or a making new > > > extension. My proposals touch existent files (and compose subsytem) > > > only. > > > > I agree that the Compose configuration should be integrated into XKB. > > However, I'd think that you could leave the old Xlib stuff the way it is. > > If Jane Doe wants to be able to have personal Compose sequences, she has > > to enable XKB. Of course, that's only if it's less work to develop and > > maintain. > > > > Also, what I understand is that you want to change XKB to provide compose > > sequences. Will that break interoperabilty with non XFree86 servers or > > clients compiled with non-XFree86 xlibs? > > It seems that you and Kent misunderstood me. > I know my English isn't good but I thought my sentences "An ideal solution > would be ... but it needs ..." and "my proposals touch existent ... only" > don't contain any ambiguity. :-) > > I *don't want* to change XKB protocol namely because it can "break > interoperabilty with ...".
Ah, OK. I didn't realize that "touching existent ... only" meant the Xlib/non-XKB way. > > I guess before I can say anything intelligent about this style of > > customization, I'd want to know what is the method for configuring a > > private XKB keymap? The classic way is with xmodmap, but that's not at > > all XKBish. What should a user do to select an XKB symbol map in his home > > directory? Put setxkbmap -symbols $HOME/.xkb/mycustom or something? > > No. The setxkbmap program doesn't read and load keyboard map files to > Xserver. It just sends *names* of files to Xserver and then the server > reads those files from its 'database'. Since a users home directory and > the server can be on different machines, you can't send an arbitrary file > in such way. > > But a user can use xkbcomp that is able to read files from the users > directory, compile them and then send a keyboard map to the server using > XKB protocol. But since XKB protocol doesn't deal with Compose files > xkbcomp is useless for such task. ... > BTW, KDE and Gnome tools use setxkbmap (or the calls setckbmap uses) and > therefore can't load an arbitrary users file to a server too. They just > send names of keyboard map files that a user prefers. But those files > should exist in the servers 'database'. So KDE and Gnome could compile an XKB keymap and send it from the client to the Xserver. Just that it's easier to allow the server to set the policy for this (and force the end-user to use xmodmap to get custom configuration). > > > In finally a most doubtfull part: how to specify needed Compose file. > > > Now I made an environment variable XCOMPOSEFILE which value should be a > > > name (with a path) of Compose file. But I realize it is unhandly for > > > users. Any ideas are welcome. > > > > Ug. As in Ug-ly. Desktop-level customization by environment variables is > > pretty crappy. I'd rather see something that was more general to XKB, > > too. > > I can offer another way. Let setxkbmap stores a name of compose file in > some root window property. And Xlib reads this name from the server but > a complete path to the directory that contains all those files is > compiled-in into Xlib. > > But such method can cause problems when a client and a server are on > diferent computers runing different versions of X's because the client > application gets the name of a file from a server but reads the file itself > from the local filesystem. So currently, the Xlib keyboard customization (including compose) all exists on the client side, but the XKB customization (not including compose) exists more on the server side. You want to allow end-users (sitting in front of the Xserver) to be able to configure the compose on the client side. You end up with a similar problem as the Xkb stuff described above, where the client side only has a filename for it's key to the database, but limited ability to send real data. The two points that you brought up for making these changes were "Locale Independance" and "Customization." I think that unless the Customization can be done via XKB, it should not be done at all. XFree86 already confuses any user who tries to configure a keyboard -- there are too many conflciting, half-implemented configuration methods. However, Locale Independance sounds like it would be fairly easy to implement and have the added benefit of removing one of the keyboard configuration methods. I imagine that would reduce the frustration of users. However, I don't totally understand your explaination here: > If the result of a compose rule ia a keysym only Xlibhas to convert it to a > string according to the current locale in the way used for usual key > press/release events. It this case one compose files can be used for > different locales and depends on a keybord map only. It seems like you're saying that instead of using a locale, the compose config would be chosen as a result of the keymap chosen. If that's true, that sounds like a great solution to the Locale problem. Unless per-user customization is really, really pressing, I wouldn't add it (outside of the "ideal" Xkb solution. What do you think? Frank _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
