<<>> <> <> <> <> <<>> Todo for next release Remove KeySymsKB.QuestionMark. Scheifler admitted this to be a bug in the specification -------------------------- Shared keyboard relative types between X11 software and viewers software. A KeyCode is a machine [and time] dependent identification of a key A KeySym is an universal identification which refers (roughly) to the engravings found on the keycaps of keyboards key engravings. Values are defined and registered by the X Consortium. The Cedar Interfaces KeyTypes.mesa is a minimal definitions module defining KeyCode and KeySym. The meaning of KeyCode's and KeySym's are defined by the X Consortium; this packages defines data types which prevent erronous usage by using unique types. The df file also includes some more modules for accessing and converting types relevant in the context of keyboards. I.e. the RelativeTimes.mesa module looks harmless vanilla Cedarish, but has been designed to fit the model of X timestamps. In addition there are some modules defining ranges of KeySym's. KeySyms1.mesa defines the lower half of "Latin-1 KeySym" set KeySymsKB.mesa defines the "Keyboard KeySym" set KeySymsPrincOpsConvention.mesa is a lift of the previously defined KeySyms in the old module KeyGlyps.mesa. It is not known to me which are really used or not. I discourage use of this module and look forward to retiring it. Many keysyms use blatantly illegal values. KeySymsSun.mesa defines the keysyms which have been registered at the X consortium by Sun MicroSystems INC. It has "nothing" to do with what is on a Sun keyboard. KeySymsPhysicalSuns.mesa defines the keysyms which are useful to describe the keyboards of the Sun SPARC machines. It has nothing to do with any registrations from Sun MicroSystems INC. Why Sun MicroSystems registers a different set of keys as they sell on their keyboards beats me. KeySymsCedar.mesa defines the keysyms which were used by Cedar viewers and Tioga, for which I thought the use was to deep to be changed, or, really justified. KeySymsTrackball.mesa defines the keysyms which are used for Ken Pier's TrackBall implementation. SpecialKeySyms.mesa defines keysyms which are used by both the TIP software and Xl to encode mouse buttons in the keysym space. This has been registered with the X consortium. KeySymsPublish.mesa ought to define the keysyms in the Publish set. It is very uncomplete but has been written because I was not ble to completely remove all references to these keysyms from the Cedar system. KeySymsOSF.mesa defines the keysyms which were registered at the X consortium by OSF. KeySymsHP.mesa defines the keysyms which were registered at the X consortium by HP. KeySymsDEC.mesa defines the keysyms which were registered at the X consortium by DEC. KeySymsIntergraph.mesa defines the keysyms which were registered at the X consortium by Integraph. Unrelated clients ought to expect no out of release changes to KeyTypes.mesa. However KeySyms1.mesa and KeySymsKB.mesa might be changed in case of errors corrections. They should not be imported into definition modules. KeySymsPrincOpsConvention.mesa is not used outside of the Cedar Viewers software yet and definitely should not be imported into definition modules. The registered extensions by diverse companies ought not to be used gratuitously. It is noted that those registrations contain duplications and contradictions. They have been ported to Cedar because Cedar wants to understand the important cut and paste keys from many vendors for reasons of easy portability. Allocated Keysyms This piece of documentation does not describe Cedar, but language independent registration of KeySyms. I (Christian Jacobi) would appreciate to be consulted before other KeySyms are made up for Cedar. I would also like to be consulted before other KeySyms are registered for Xerox at the X consortium. I do not have the intention of censorship, but would like to see that no conflicts occur. Of course not all Xerox KeySyms are really registered, as we wait with registration until the need has been really proven. I have tried to find some grouping of numbers which would allow including missing entries and, a the same time be quite greedy with the reserved space so the X consortium would not complain. The following keysyms are registered with the X Consortium (See SpecialKeySyms.mesa) (Used by Xl.mesa internally) Button1: KeySym = [010070001H]; --XeroxXK_PointerButton1 Button2: KeySym = [010070002H]; --XeroxXK_PointerButton2 Button3: KeySym = [010070003H]; --XeroxXK_PointerButton3 Button4: KeySym = [010070004H]; --XeroxXK_PointerButton4 Button5: KeySym = [010070005H]; --XeroxXK_PointerButton5 The following keysyms are not really registered with the X Consortium, but I have placed them carefully into the range of keysyms which the Consortium is probably keeping reserved for Xerox. (See KeySymsCedar.mesa) <> (Used by ?) CharCode0UpArrow: KeySym = [010070010H]; CharCode0LeftArrow: KeySym = [010070011H]; <> <<(Used by many Cedar tip tables)>> Swat: KeySym = [010070015H]; Look: KeySym = [010070016H]; (See KeySymsTrackball.mesa) <<(Ask Ken Pier)>> TrackballLeft: KeySym = [010070018H]; TrackballMiddle: KeySym = [010070019H]; TrackballRight: KeySym = [01007001AH]; Trackball: KeySym = [01007001BH]; Thumbwheel: KeySym = [01007001CH]; (See KeySymsPhysicalSuns.mesa) <<(Used by ?; occurs in some tip tables)>> UniqueF11: KeySym = [010070021H]; UniqueF12: KeySym = [010070022H]; <> Compose: KeySym = [010070026H]; KeypadIns: KeySym = [010070027H]; KeypadDel: KeySym = [010070028H]; Proposal: If other Xerox units