[I18n] AltGr for ISO_Level3_Shift
I'm having trouble using FOUR_LEVEL key groups Here's an example xkb
map to remap my space bar to produce the letters A, B, C, D:
partial default alphanumeric_keys
xkb_symbols "basic" {
key.type[Group1]="FOUR_LEVEL";
key { [ A, B, C, D ] };
key { type[Group1]="TWO_LEVEL", [ ISO_Level3_Shift, Multi_key ] };
};
>From my understanding, this map should function like this:
Space -> A
Shift+Space -> B
AltGr+Space -> C
AltGr+Shift+Space -> D
So I place the map in my X11/xkb/symbols/pc directory (with the rest of
the maps) and load it with:
setxkbmap -rules xfree86 -model pc104 -layout "us,space" \
-option "" -option "grp:ctrl_shift_toggle"
But at a command line (xterm/tcsh), the A & B mappings work, but pressing
AltGr+Space or AltGr+Shift+Space does not produce C or D, respectively.
However, I tried xev ("print contents of X events"), and I can see the
A,B,C,D keysyms just fine (below). Any idea what's wrong? Could the
application still be trying to interpret the AltGr key or something?
I'm running XFree86 4.3.0. (if that helps...)
KeyPress event, serial 26, synthetic NO, window 0x161,
root 0x48, subw 0x0, time 332437917, (85,65), root:(1422,86),
state 0x2000, keycode 65 (keysym 0x41, A), same_screen YES,
XLookupString gives 1 bytes: "A"
...
KeyPress event, serial 26, synthetic NO, window 0x161,
root 0x48, subw 0x0, time 332438995, (85,65), root:(1422,86),
state 0x2001, keycode 65 (keysym 0x42, B), same_screen YES,
XLookupString gives 1 bytes: "B"
...
KeyPress event, serial 26, synthetic NO, window 0x161,
root 0x48, subw 0x0, time 332440895, (85,65), root:(1422,86),
state 0x2008, keycode 65 (keysym 0x43, C), same_screen YES,
XLookupString gives 1 bytes: "C"
...
KeyPress event, serial 26, synthetic NO, window 0x161,
root 0x48, subw 0x0, time 332442642, (85,65), root:(1422,86),
state 0x2009, keycode 65 (keysym 0x44, D), same_screen YES,
XLookupString gives 1 bytes: "D"
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Compose files.
(Excuse my late reply to this, I simply forgot about it.) On Thu, Aug 28, 2003 at 03:54:11PM +0700, Ivan Pascal wrote: ..[snip].. > Locale independence. > > In existent files a compose rule consists of two parts. A 'left side' part is > a sequence of keysym and a right part (the result of composing) is a pair of > a mylti_byte string and a keysym. Both members ot that pair are independed. > Each of them can be omited and the compose subsystem doesn't check any > matching between them and doesn't figure out any one of them from other. Ah, so you mean that we can simply omit the string part of the rule, and it will work just fine with only the keysym part? Well, that's great to hear. :^) Thanks to your work on "unicode keysyms", there's really no need for the string part these days, so we could indeed have completely locale independent Compose files. Very nice. :^) > Customization. > > I added to Compose file an 'include' instriction. It allows to compose > Compose file :-) from some files and add small corrections that user prefers. > E.g. if user has custom Compose file it can look like > > include "" > my_own_rules > ... > > Of course, if some rules overlap, Xlib just discards a previous rule and uses > latest one. Oh, so in combination with the above, we can now have locale independent Compose file snippets, that can be included to form the full files. Wonderful. Even with the existing configuration framework (Compose gets defined by the locale) this would immediately solve a couple of problems for me, namely: - No more having to maintain separate files with the exact same definitions for different character sets, ISO-8859-7 and UTF-8 in my case. Just write the snippets and include them as necessary. - No more having rules of limited use because they exist in one locale only. Right now, to use decent polytonic greek compose rules, one has to switch to el_GR.UTF-8. But with your work included, I could split these rules to a separate file, which could easily be included by any locale. And some more, such as: - With includes, it would be very easy to accommodate requests like "in Brazilian locales dead_acute+c should produce ccedilla" with minimal duplication of code. - We could broaden the compose definitions even for 8-bit locales, so that Unicode-aware applications (such as Mozilla) would use them under any locale. If these changes go in, I guess we will probably need a directory /usr/X11R6/lib/X11/locale/include to place such included files. > Also I think some substitutions in the included file name could be usefull. > A made two ones: %H means the value of HOME variable and %L means the name > with full path to a currently used local-depended file (e.g > /usr/X11R6/lib/X11/locale/iso8859-1/Compose). > The first substitution woild allow to add a per-user preference file into > a 'system' Compose file, e.g. > > system-wide file: > common_rules > ... > include "%H/.XCompose" > > If the file doesn't exist Xlib silently ignores such instruction. > > The second substitution would allow user to add currently used files into own > custom Compose file without care where that file is actually placed. No objections here. Just don't forget to add at least another substitution, %%, which produces a literal %, for completeness' sake. > 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. Hm, how about simply checking for the presence of ~/.Xcompose and using it instead of the locale dependent file? In that case, this file would have to include the system wide ones instead of the other way round, so perhaps the substitutions you've proposed wouldn't be really needed. > P.S. All changes I'm talking about are already made and tested. I can commit > them in any time. But I'd like to hear suggestions/objections. Indeed, once we've settled all the issues, committing is the right thing to do. :^) Again, great work! -- Vasilis Vasaitis [EMAIL PROTECTED] +306976604701 ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Compose files.
> > > 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, t
RE: [I18n] Compose files.
Ivan Pascal wrote: > > > An ideal solution would be to integrate compose rules into XKB (or core > > > protocols) maps but it needs changes in the protocol or a ... > > It seems that you and Kent misunderstood me. No, just trying to push in the right direction. > I *don't want* to change XKB protocol namely because it can "break > interoperabilty with ...". Is there no backwards compatible way of doing such an extension? Old version will not get new functionality (but have to rely on the old way). But old systems interoperating with new ones shouldn't "break" anyway. /kent k ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Compose files.
Hello, > > 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 ...". > 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. > Then the KDE and > Gnome tools that modify XKB from the client side can do the same thing for > Compose as they do for the XKB symbols. 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'. > > Of course, if some rules overlap, Xlib just discards a previous rule and > > uses latest one. > > Xlib or XKB? Or both/either? I ment Xlib's ones only. :-) > > 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. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
