On Mon, Sep 17, 2001 at 11:11:27AM +0200, Peder Stray wrote: > Dominik Vogt <[EMAIL PROTECTED]> writes: > > > I made the patch/fix (whatever one may call it) that changed this > > behaviour because the same code broke handling of the function keys: > > on some setups, F11 and Shift-F1 both generate the key symbol "F11". > > Now consider you treat S = shift-s = s and thus F11 = shift-F1 = F1. > > It's not possible to distinguish between both. The old code bound > > the same action to the F11 key and the F1 key and thus removed any > > previous binding on the F1 key. The fix was to imply the Shift > > modifier in this situation - and that is responsible for your > > problem. I can well imagine there are quite a few configs out there > > that rely on upper case letters, but I don't know what to do about > > it without breaking function key again. > > well, lets see what xev says about it... > > first we have S (with capslock): > > S > KeyRelease event, serial 13, synthetic NO, window 0x280000e, > root 0x25, subw 0x2800015, time 4284515974, (193,128), root:(704,747), > state 0x2, keycode 39 (keysym 0x53, S), same_screen YES, > XLookupString gives 1 characters: "S" > > then shift-s: > > S > KeyRelease event, serial 13, synthetic NO, window 0x280000e, > root 0x25, subw 0x2800015, time 4284546841, (173,144), root:(684,763), > state 0x1, keycode 39 (keysym 0x53, S), same_screen YES, > XLookupString gives 1 characters: "S" > > as you can see they differ in state. as a comparison normal lowercase > s differ in keysym and state. > > s > KeyRelease event, serial 13, synthetic NO, window 0x280000e, > root 0x25, subw 0x2800015, time 4284556405, (244,150), root:(755,769), > state 0x0, keycode 39 (keysym 0x73, s), same_screen YES, > XLookupString gives 1 characters: "s" > > > Well then we look at F1, Shift-F1 and F11 > > OP > KeyRelease event, serial 13, synthetic NO, window 0x280000e, > root 0x25, subw 0x2800015, time 4284568583, (204,117), root:(715,736), > state 0x0, keycode 67 (keysym 0xffbe, F1), same_screen YES, > XLookupString gives 0 characters: "" > > [23~ > KeyRelease event, serial 13, synthetic NO, window 0x280000e, > root 0x25, subw 0x2800015, time 4284579325, (180,123), root:(691,742), > state 0x1, keycode 67 (keysym 0xffbe, F1), same_screen YES, > XLookupString gives 0 characters: "" > > [23~ > KeyRelease event, serial 13, synthetic NO, window 0x280000e, > root 0x25, subw 0x2800015, time 4284588062, (253,154), root:(764,773), > state 0x0, keycode 95 (keysym 0xffc8, F11), same_screen YES, > XLookupString gives 0 characters: "" > > Shift-F1 and F11 differ both in state and keysym, but they return the > same string... > > so i really dont see how this could be a problem... and at least not > why S should imply the shift modifier compared to s...
The problem is what the user expects: Key F11 A N Beep Should this bind only the unmodified F11 key or shift-F1 too? Due too a lot of user complaints, fvwm binds both. Actually, the fact that the binding Key S ... worked in the past is more or less a bug - although a convenient one. The keysym on the s key without modifiers is "s" not "S". If it were "foobar" you'd certainly expect Key foobar ... to only bind "shift-s", not "s" itself, but we are all used to treat upper and lower case letters as equal - while X11 does not. Anyway, I think I have a solution: Whenever a key is bound, the key name is always translated to lower case before checking if a key with this name exists. Only if it does not, the upper case spelling is used. This would take care of s/S or odiaresis/Odiaresis, but will of course fail miserably if the two symbols are bound to different keys. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
