DAN@YKTVMV.BITNET (03/04/88)
I am trying to adopt X.11 to run on an RT with 4.3 and a Swedish keyboard. Actually I do not have any problem with our national charaters ( they are printed on the top of keys ), which I just map with XChangeKeyboardMapping. My problem is some of the US ASCII characters, which are printed on the front of some keys ( eg left square bracket is on front of the key with digit 8 ) We like to use the 'alt' key as a modifier to get these 'keysyms' engraved on the fronts. I understand that I will have to redefine the array of KeySymS, from the default two columns to (at least) three columns, when I have to bind the modifier mapping eg XsetModifierMapping ( keycode of 'alt' to Mod1 ) Now to my question HOW, do I set Mod1 to point to column three in the array of KeySyms ???? (First column is unshifted, second column is Shift/Lock, but following columns are undefined by Xlib ||||????) Any Hints would be much apriciated. Regards H.Winbom
dshr@SUN.COM (David Rosenthal) (03/13/88)
Now to my question HOW, do I set Mod1 to point to column three in the array of KeySyms ???? Your model of how keystrokes are reported is wrong. The server's responsibility is to: - report keycodes as keys go up and down. - report what is written on these keys. - report the state of modifier bits on several event types. - permit arbitrary keys to be used to control these modifier bits. Assigning meaning to these events is entirely the client's responsibility. The interpretation, for example, of a keycode 0x20 down as an "a" and a keycode 0x20 down with modifier "Shift" set as an "A" is entirely a matter for the client, and that is why it is implemented in Xlib. If you want to use an extended character set, you will need to replace XLookupString() - which is specific to ASCII - with a XLookupFOOString() where FOO is the name of your extended character set. Note that this means that the client is specific to one or more character set encodings. This is as it should be - having a server which was specific to a particular encoding would be inconvenient. So, for example, to implement an Elvish xterm, you decide on an encoding for Elvish, select an Elvish font with that encoding, check the response to the GetKeyboardMapping request to determine if the keyboard you are talking to has the Elvish keysyms on it, write an XLookupElvishString() function, and call it to decode the events you get. The fact that the Elvish xterm uses the BAR key to select the keysyms that are written (in Elvish script) on the sides of the keys is entirely private - it does not affect the Dwarvish xterm which you may also be running. David.
george@mnetor.UUCP (George Hart) (03/15/88)
In article <8803130226.AA20908@devnull.sun.com> dshr@SUN.COM (David Rosenthal) writes: ... >Your model of how keystrokes are reported is wrong. > >The server's responsibility is to: > >- report keycodes as keys go up and down. I'm curious about this. Many keyboards do *not* report up/down shift codes. Nor do they report shift states. Instead, they do all the translation in the keyboard. How does X11 accomodate these keyboards? Better still, how do well do typical programs, which expect the extra info, function in the absence of such info? -- Regards, George Hart, Computer X Canada Ltd. NOW REAL SOON NOW UUCP: utzoo UUCP: utzoo >!mnetor!george > cxhi!george uunet uunet BELL: (416)475-8980