[OFB Cafe] keyboard remapping, etc.

[Kris Deugau]

dep wrote:
> yup. tried to do the same thing. i've been thinking that in the guts of the 
> keyboard mapping there is a way around this, though.

Mmmh.  From experience I'm guessing it may require very low-level keymap 
tweaking.  :(  Some of the misbehaviours I see happen even in a console 
shell.

> "NumLock on KDE Startup
> "( ) Turn on
> "( ) Turm off
> "( ) Leave unchanged"
> 
> which, even if it isn't in kcontrol, has to be hidden in a config file 
> somewhere in ~/.kde.

Actually, I usually set it in BIOS.  <g>  The problem is inconsistent 
handling between applications though;  there are three behaviours I've seen:

1) "Correct" behaviour where arrow keys are arrow keys and only in rare 
specific cases are they number keys - I can use Shift+<arrow> with 
*both* the inverted-T and the keypad (with Numlock off) to select text, 
spreadsheet cells, etc.

2) Thoroughly incorrect behaviour where the keypad is never ever *EVER* 
interpreted as arrow keys no matter what the state of Numlock and 
whether Shift is held down or not.  I had trouble with this with SSH 
access to Debian woody (IIRC) using nano/pico (one or the other;  don't 
recall offhand which it actually was).  Setting the TERM environment 
variable seemed to help fix things, sometimes.

3) Almost-correct behaviour in which Numlock correctly determines 
whether the keypad is numeric or arrow keys;  but I can't use 
Shift-<keypad> keyboard selection.

Without touching keyboard settings, I can have all three behaviours in 
different apps.  Windows at least keeps things consistent.  :/

-kgd