From: hdsrjh@hds.UUCP (Randy Huggins)
Newsgroups: comp.windows.x.motif
Subject: keyboard event transformations
Date: 5 Nov 92 14:21:40 GMT
Distribution: inet
Organization: Hierarchical Development Systems, Inc.

Hello.

I'm currently trying to solve a problem where my Motif application's
text widgets don't honor the arrow keys when I run with the OpenWindows
2.0 XNeWS server and olwm, but works fine with the OpenWindows
3.0 XNeWS servers/olwm and the MIT server/mwm.  However, I'd rather 
not get a 'cookbook' answer.  I'm trying to understand this processing
thread from keypress through widget action routine once and for all.

I've waded though O'Reilly volumes 1 through 6, read and re-read
FAQ's 102, 103, and 104, played with 'xev', and tried numerous
experiments, but I'm still missing several somethings.  

The 'short form' question is:

	What is the sequence of transforms by which a Motif client, using
	MIT Xlib/Xt, converts a KeyPress event into the Motif 'virtual key'?
	Secondarily, what code does them?  Beyond that, why aren't the 
	transforms IDENTICAL for a statically linked Motif application
	when it is run with an MIT, OW2.0 or OW3.0 X server?

For completeness, I run X11R4/Motif 1.1.1 from ICS, and both
Openwindows 2.0 and 3.0 from [who else?] Sun.  I always link my Motif
application -Bstatic to the ICS libraries, so I never mix the
Motif widget code with the Sun X11/Xt libraries.

As you will see below, I DO have a /usr/lib/X11/XKeysymDB with the osf 
stuff in it.  I also have a ~/.motifbind, but I don't think that is 
relevant for the OpenWindows environments in which my Motif appl runs.  
I also don't have a *defaultVirtualBindings resource defined.

The 'long form' question, containing facts I have gleaned and 
sub-questions is:

	   For my immediate problem with the arrow keys, 'xmodmap -pk' 
	   tells me something like the following for ALL server environments:

       98    	0xff51 (Left)	0xffdb (F30)	0xffb4 (KP_4)	
	   
       KeyPress events identify the keycode, so the client must
       be responsible for ALL the transforms. It would seem that
       the client must call XKeycodeToKeysym() first to convert the '98'
       to '0xff51' and then call XKeysymToString() to convert 
       '0xff51' to 'Left' [or osfLeft ???].

	   XKeysymDB.  I copied my ICS-supplied XKeysymDB
	   to /usr/lib/X11, and it has entries like:
	   			osfLeft				:1004FF51
	   OpenWindows3.0 came with its own, which has entries like:
				osfXK_Left:			1004FF51

			Q1) What is the '1004' stuff that precedes what must
				be the raw keysym value?  I can make the arrow
				keys work under OW2.0 by deleting the '1004' but
				that CAN'T be the real solution.
			Q2) XKeysymToString() must be the logic that references
			    XKeysymDB under SOME circumstances.  Is his caller 
			    responsible for pre-pending the '1004' stuff to the
			    keysym, and failing to do so under OW2.0?

	   FAQ question 103 talks about "...installing a virtual keysym 
	   translator ANYWAY...", asserting this relative to a missing 
	   XKeysymDB.  The fact that I don't understand this FAQ may be
	   indicative of why I am struggling.
	   
       The OSF/Programmer's Reference on pages 1-163 to 1-165, talks 
       about Fallback Default Bindings of "osf" Keysyms to keysyms,
       but really muddies the water for me.  They are not
	   talking about a missing XKeysymDB, they are talking about a 
	   the absence of a _MOTIF_BINDINGS property or a missing 
	   XmNDefaultVirtualBindings resource.  In the table, they show
	   a fallback default binding of 'osfLeft' to 'Left'.
	   
       From the OSF Programmer's Guide, (pg 1-162), we see what must 
       be the hardcoded bindings of 'virtual' keys to the result of some
       prior transforms, e.g.  KLeft   :   <Key>osfLeft.   I must not
       have such an osfLeft key event under OW2.0, but I don't know why, 
       or who didn't apply a transform.

       Then the OSF book has another table (pg 1-165) about the bindings 
       of 'osf' keysyms [to events?] and some prose abount a precedence 
       hierarchy and defaults based on the vendor string returned from the 
       X server during XOpenDisplay().  What string???  Is this the 
       difference I see between OW2.0 and OW3.0???

       I have a $HOME/.motifbind file, which looks like: 
       		osfLeft		:		<Key>Left
			osfRight	:		<Key>Right
	   but only 'mwm' loads it onto the _MOTIF_BINDINGS property, so I
	   am assuming that I am using the default bindings talked about
	   above when I run with EITHER OpenWindows server.  The default 
	   bindings shown in the OSF Programmer's Guide look about
	   the same as my .motifbind file for these keys.  I conclude
	   from this that this level of transformation is constant for my
	   statically linked application across server environments.
	   
I guess this is the heart of my confusion.  If the 'KLeft' virtual key
is ALWAYS derived from '<Key>osfLeft', (OSF Programmer's Guide page 1-162)
and [given the absence of _MOTIF_BINDINGS or XmNdefaultVirtualBindings]
'osfLeft' BY DEFAULT is bound to 'Left' (OSF Programmer's Guide page 
1-165), when does the 'osf' XKeysymDB stuff get involved? 

I would greatly [immensely] appreciate any light anyone can shed on this.
I'm wandering aimlessly through a forest of disconnected facts.

-R
hds!hdsrjh@liberty.East.Sun.COM
Newsgroups: comp.windows.x.motif