Proposed changes to key trapping code

[Benjamin K Cook]

Hi -

Here's what I think would be a simple but effective fix for trapping
special keys within the vtk*RenderWindowInteractor event-handling code.  
An outstanding question is whether users want the code to try to trap
"all" special keys (which brings into play keyboard differences), or
whether a smallish subset would do, say just the  arrow  and
editing keys.  Some of the feedback I received from my earlier post
argued that trapping ASCII keys was probably sufficient for most vtk
users. I've found, however, that some special keys, e.g. the arrow keys,
offer a more intuitive control; it  would be handy if vtk users
could trap these events without having to hack up the core vtk
code or write their own event-handling interface.    

Briefly, using an extended "character" set defined in
vtkRenderWindowInteractor.h,
e.g.,

#define VTKI_UP_KEY -128  
#define VTKI_RIGHT_KEY -127 
and so on ... 

we can implement a platform-independent solution that works within the
constraints of the existing keypress callback interface,
void vtkInteractorStyle::OnChar(int ctrl, int shift,char keycode, int
vtkNotUsed(repeatcount)).  I've included below my X
changes to vtkXRenderWindowInteractorCallback(...), Win32 changes
would be along the lines of those offered by Nigel Nunn in his May 18
posting, i.e., a WM_KEYDOWN case with the necessary checks against VK_* in  
vtkHandleMessage().

In case KeyPress: at  ~ Line 540 in vtkXRenderWindowInteractor.cxx:
 
 // charPress is a flag that indicates whether the key pressed is a 
 // recognized character or a special key
 int charPress = 0;
 charPress =  XLookupString((XKeyEvent *)event,buffer,20,&ks,NULL);
 if(!charPress)
   {
   switch (ks)  //try to match ks with symbols defined in X11/keysymdef.h
     {
     case XK_Up:
       buffer[0] = VTKI_UP_KEY;
       break;
     case XK_Right:
       buffer[0] = VTKI_RIGHT_KEY;
       break;
     case XK_Down:
       buffer[0] = VTKI_DOWN_KEY;
       break;
     case XK_Left:
       buffer[0] = VTKI_LEFT_KEY;
       break;
     default:  
       buffer[0] = VTKI_UNKNOWN_KEY;
       break;
     }
   }

An slightly more involved alternative is to extend vtkInteractorStyle with
a compliment function to OnChar(), say OnSpecial(), that is called instead
of OnChar when a special key has been pressed (this is what GLUT does).
Its not clear to me that there's a big advantage to this approach.

If these changes will work, I guess we'll need to decide which special
keys to trap  and coordinate the Win32 and X revisions accordingly.  

Ben Cook



--------------------------------------------------------------------
This is the private VTK discussion list. Please keep messages on-topic.
Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at public.kitware.com>. For help, send message body containing
"info vtkusers" to the same address.
--------------------------------------------------------------------