hvr@eng.sun.COM (Heather Rose) (05/09/90)
> From: sitongia@hao.ucar.edu (Leonard Sitongia) > Newsgroups: comp.windows.x > Subject: Getting function key events to application under OLWM/CMDTOOL? > > Under twm/xterm, Sun keyboard function keys pass transparently to the > application running. Under olwm/cmdtool, they are intercepted and > interpreted by olwm, I guess. This appears to be for all the F, R and L > function keys, not just the ones that have functions I know of (help, > cut, paste, etc.). One can observe which keys are "pre-procesed" by olwm and which ones are not with the program "xev" which prints out the events it gets. Using xev, it becomes apparent that OLWM does something special with 3 keys: "Front", "Open", and "Help" on the type4 Sun keyboard. In version 2 of OLWM, it will read from the resources database which keysym should map to each of these actions. The "Help" key is special in that OLWM creates a synthetic event for the help action. The next stage is to see what kind of "pre-processing" is being done to the events by the default XView behavior. One can observe this behavior by creating a canvas, asking for all events, and then see what is printed out by the canvas when the events happen. I did this by making some slight modifications to the xev program. No suprise, the results in the XView canvas were the same as the results in the Xlib, xev, window. So, OLWM and basic XView do not do anything significant to the function keys. Thus, the behavior you're observing is part of the behavior of the XView packages TTYSW and TEXTSW which comprise the TERM class of which cmdtool is an instance. Both of these packages do a significant amount of processing of events, but do they do anything special with function keys? Well, yes if the function keys have been mapped to something; otherwise, no action is taken. The TEXTSW will read in the file $HOME/.textswrc for mappings. The default action to take is to read the contents of the current primary selection, fork the program given using the selection contents as stdin for the program, then insert the stdout of the program at the current insertion point of the window. If the selection was made in pending-delete mode which is the default, the output of the program will take the place of the contents of the selection if they are in the same window. For example, let's say you want to map a function key to run indent on the code you're editing with textedit, you add to the .textswrc file: F7 FILTER indent -st Then, make a selection of the text and hit the "F7" key which is labeled "F7" on the type4 Sun keyboard. The code has now been replaced with the version run through indent. The TTYSW will read the file $HOME/.ttyswrc for mappings. This allows one to specify whether a mapping is to be considered part of the output stream or input stream of the terminal emulator. Those for the input stream will be executed by the shell. For example, print out the name of the key hit: mapi F7 echo "Got key F7" The TERM package will read in both the .ttyswrc and the .textswrc where the .texswrc values will take precedence over the .ttyswrc values. So, in the example above, cmdtool will always use the filter specified instead of the echo command. There's a bug in TERM package where it does not do anything with the .ttyswrc mappings. This has been fixed for release 2 of XView. Thus, where the mappings specified in .ttyswrc will work for a shelltool (or a cmdtool with scrolling disabled), they currently do not work for a cmdtool (or a shelltool with scrolling enabled). In addition, these packages, TTYSW and TEXTSW, give special meaning to other keysyms according to some pre-defined actions. Most of the Left keys on the type4 keyboard have actions associated with them. There's an outstanding RFE (request for enhancement) to allow one to re-map these actions to other keysyms; however, this will not be included in the next release. There's another "feature" of the TTYSW package which will output an escape sequence for the arrow keys: keysyms Up, Down, Left, Right. I believe this was added because some programs have been altered to expect these sequences. i.e "vi" is one. If that is a problem, one can use xmodmap to change the keysyms to the corresponding function keysyms (use xev to see which keycode is associated with a keysym, the shift state of the keyboard also has an effect). > We have an application in which uses function keys and runs in a cmdtool > window. For now, either use shelltool or xterm. > How can I tell cmdtool/olwm to pass some set of function keys transparently > to the application? The problem is that "what" these windows should pass to you is not defined yet. The mapping for the keysym needs to be defined in the .ttyswrc file. > Under SunView, the .ttyswrc file may be used to remap keyboard function. > Why doesnt this work in the OpenWindows cmdtool like it does in the > SunView cmdtool? bug. as mentioned above which will be fixed for release 2 of XView due out sometime this summer. Regards, Heather