Num-Lock proposed fix

[Maurizio DE CECCO]

"Peter C. Mehlitz" <peter at transvirtual.com> writes:

> 'VK_NUMx' keyConst, and 'x' keyChar makes sense (otherwise, the VK_NUMs would
> be pretty useless). I'll check how I can add it to the event handling (there
> was a bug for KEY_TYPED function keys, anyway).

I found a bug relative to function keys, i suppose it is the same;
what i found was that since the FKeyCode table was typed signed char,
keycode bigger than 127 where erroneously reported as non pure
functions keys, so for example Ins inserted an 'e'.

I include in the following my patch; the above bug is fixed in the
patch by typing the FKeyCode table as 'signed short' (but is suppose there
are more elegant solutions :).

About the event handling, i used the key symbol optionally returned by
XLookupString, that *do* use the modifiers, including NumLock, to
analyse the keycode; if the basic, unprocessed keysymbol returned by
XKeycodeToKeysym correspond to a keypad symbol, i use the symbol
returned by XLookupString for the X keysym to Java keycode
translation, otherwise i use the original one; than, a small piece of
code add the expected keychar code to the keypad symbols.

It seems convoluted, but the problem is that finding out which X
modifier represent the NumLock seems to be quite complex (i asked our
X window expert) because it depends on the server configuration; with
this implementation, the work is done by the Xlib.

Let me know if this solution works for you, and if you find a better solution :->

Maurizio

--- snip ---------------------------------------------------------------------
diff -ru kaffe-1.0.5.orig/libraries/clib/awt/X/evt.c kaffe-1.0.5/libraries/clib/awt/X/evt.c
--- kaffe-1.0.5.orig/libraries/clib/awt/X/evt.c	Mon Oct 18 07:24:02 1999
+++ kaffe-1.0.5/libraries/clib/awt/X/evt.c	Wed Apr 12 14:58:34 2000
@@ -11,6 +11,7 @@
 
 #include <X11/Xlib.h>
 #include <X11/Xutil.h>
+#include <X11/keysym.h>
 #include "toolkit.h"
 #include "keysyms.h"
 
@@ -218,19 +219,97 @@
 keyNotify ( JNIEnv* env, Toolkit* X )
 {
   KeySym          keysym;
+  KeySym          keysym2;
   XComposeStatus  ioStatus;
-  int             n, keyCode, keyChar, mod, idx;
+  int             n, keyCode, keyChar, mod, idx, nchar;
 
   /*
    * We should eventually support input methods here.
    * Note that 'keysym' is queried separately (with a standard state), to
    * ensure the "one physical key -> one keycode" invariant
    */
-  n = XLookupString( &X->event.xkey, X->buf, X->nBuf, 0, &ioStatus);
+  n = XLookupString( &X->event.xkey, X->buf, X->nBuf, &keysym2, &ioStatus);
   keysym = XKeycodeToKeysym( X->dsp, X->event.xkey.keycode, 0);
 
+
+  // Bug fix: the keypad numbers where not handled correctly.
+  // In X, numlock is a modifier, and XKeycodeToKeysym do
+  // not do any modifier interpretation (in order to
+  // build the correct Java KeyEvent).
+  // But, as a result, since there is no NumLock modifier
+  // in Java, the information was lost, and the keypad could
+  // not work with NumLock selected.
+  // The "solution" is to use the returned keysym from XLookupString
+  // (which interpret the modifiers) if and only if it 
+  // the original keysym correspond to the keypad; this should
+  // code will all the case where the numlock alter the interpretation
+  // of the keypad; also, if the keysums are the xk_xp_<num> 
+  // we set the keychar to the correspoding digit.
+
+  if ((keysym >= XK_KP_Space) && (keysym <= XK_KP_9)) {
+      keysym = keysym2;
+      
+      switch (keysym)
+	{
+	case XK_KP_Multiply:
+	  nchar = '*';
+	  break;
+	case XK_KP_Add:
+	  nchar = '+';
+	  break;
+	case XK_KP_Separator:
+	  nchar = ',';
+	  break;
+	case XK_KP_Subtract:
+	  nchar = '-';
+	  break;
+	case XK_KP_Decimal:
+	  nchar = '.';
+	  break;
+	case XK_KP_Divide:
+	  nchar = '/';
+	  break;
+	case XK_KP_0:
+	  nchar = '0';
+	  break;
+	case XK_KP_1:
+	  nchar = '1';
+	  break;
+	case XK_KP_2:
+	  nchar = '2';
+	  break;
+	case XK_KP_3:
+	  nchar = '3';
+	  break;
+	case XK_KP_4:
+	  nchar = '4';
+	  break;
+	case XK_KP_5:
+	  nchar = '5';
+	  break;
+	case XK_KP_6:
+	  nchar = '6';
+	  break;
+	case XK_KP_7:
+	  nchar = '7';
+	  break;
+	case XK_KP_8:
+	  nchar = '8';
+	  break;
+	case XK_KP_9:
+	  nchar = '9';
+	  break;
+	default:
+	  nchar = -1;
+	  break;
+	}
+  }
+  else
+    nchar = -1;
+
   if ( (keysym >= 0xff00) || (n == 0) ) {
 	keyCode = FKeyCode[keysym & 0xff];
+
 	/*
 	 * There are some "control keys" that should generate KEY_TYPED events
 	 * (enter, cancel, backspace, del, tab). This is flagged by a negative keyCode
@@ -238,6 +317,8 @@
 	 */
 	if ( keyCode < 0 ){
 	  keyChar = keyCode = -keyCode;
+	} else if (nchar >= 0) {
+	  keyChar = nchar;
 	}
 	else {  /* a "pure" function key */
 	  keyChar = 0;
diff -ru kaffe-1.0.5.orig/libraries/clib/awt/X/keysyms.h kaffe-1.0.5/libraries/clib/awt/X/keysyms.h
--- kaffe-1.0.5.orig/libraries/clib/awt/X/keysyms.h	Mon Oct 18 07:24:02 1999
+++ kaffe-1.0.5/libraries/clib/awt/X/keysyms.h	Wed Apr 12 14:58:15 2000
@@ -22,9 +22,14 @@
  * events.
  * Note that we can't mix in latin keycodes, because even upper case letters would
  * overlap (XK_P = 0x50, XK_home = 0xff50), we have to keep them in a separate table
+ *
+ * Changed the FKeyCode from char to short; on a system where the char is 8bit, some
+ * of the code become negative (because they are bigger than 127) and
+ * produce a keytyped of unrelated characters (like "Ins", produce an 'e');
+ * (MDC, Mandrakesoft).
  */
 
-signed char FKeyCode [256] = {
+signed short FKeyCode [256] = {
 0,
 0,
 0,
@@ -437,3 +442,8 @@
 };
 
 #endif
+
+
+
+
+

--- snip ---------------------------------------------------------------------



-- 
Maurizio De Cecco
MandrakeSoft 		http://www.mandrakesoft.com/