Maurice posted on Wed, 18 May 2016 12:04:48 +0000 as excerpted: > On Tue, 17 May 2016 02:33:15 +0000, Duncan wrote: > >> So first thing, try toggling numlock and see if it works then. > > (This also applies on my Mageia-5 desktop, by the way) > > No difference whether Numlock is 'on' or 'off'. > >> Then take a look at the accels.txt file in $PANHOME (~/.pan2 by >> default). > > cat ~/.pan2/accels.txt | grep delete
> ; (gtk_accel_path "<Actions>/Actions/delete-groups-articles" > "<Primary><Shift>Delete") > ; (gtk_accel_path "<Actions>/Actions/delete-article" "Delete") OK, both entries are commented by the initial semicolon, so remain at their defaults. But you didn't report the results from xev, which will show what hitting the keys actually produces from an X perspective, and thus what pan actually sees in terms of what keys X is reporting to pan as actually pressed. For me, I get this printed by xev to my terminal window when I press the keypad ./delete key while numlock is on (and the xev window has the focus): KeyPress event, serial 40, synthetic NO, window 0x2000001, root 0x4c0, subw 0x0, time 102893822, (180,36), root:(966,3098), state 0x10, keycode 91 (keysym 0xffae, KP_Decimal), same_screen YES, XKeysymToKeycode returns keycode: 129 XLookupString gives 1 bytes: (2e) "." XmbLookupString gives 1 bytes: (2e) "." XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x2000001, root 0x4c0, subw 0x0, time 102893920, (180,36), root:(966,3098), state 0x10, keycode 91 (keysym 0xffae, KP_Decimal), same_screen YES, XKeysymToKeycode returns keycode: 129 XLookupString gives 1 bytes: (2e) "." XFilterEvent returns: False So we see two events, keypress and keyrelease, with KP_Decimal the reported keysym, and a single "." decimal point printed. (While I'm no authority on locales, I believe in other locales, KP_Decimal will remain the same, but instead of the "." it might be "," or something else.) With numlock off, xev reports this, instead: KeyPress event, serial 40, synthetic NO, window 0x2000001, root 0x4c0, subw 0x0, time 103402468, (180,119), root:(966,3181), state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x2000001, root 0x4c0, subw 0x0, time 103402569, (180,119), root:(966,3181), state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False So we see its the same keycode, but with numlock off, it's a different keysym, KP_Delete instead of KP_Decimal. And there's no lookup string now. For comparison, here's what hitting the dedicated delete key does: KeyPress event, serial 40, synthetic NO, window 0x2000001, root 0x4c0, subw 0x0, time 103659757, (178,95), root:(964,3157), state 0x0, keycode 119 (keysym 0xffff, Delete), same_screen YES, XLookupString gives 1 bytes: (7f) "" XmbLookupString gives 1 bytes: (7f) "" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x2000001, root 0x4c0, subw 0x0, time 103659857, (178,95), root:(964,3157), state 0x0, keycode 119 (keysym 0xffff, Delete), same_screen YES, XLookupString gives 1 bytes: (7f) "" XFilterEvent returns: False Different keycode, different keysym (Delete instead of KP_Delete or KP_Decimal), and interestingly enough, a different lookup string, hex 7F (decimal 127), which is indeed ASCII DEL. Based on the above, I've changed my original position some, as I previously assumed the two deletes would produce the same lookup string, even if different keysyms, so I thought if pan was responding to only one it must be responding to the keysyms. Obviously I assumed wrong. It (now) appears to me that pan (almost certainly via gtk) actually uses the lookup string, ASCII DEL, and in ordered to make the keypad delete key function similarly to the dedicated delete key, you'll need to configure X to produce the same ASCII DEL lookup string. That's out of pan scope and out of my easy area of knowledge, but I believe I can at least point you in the right direction. Take a look at xmodmap and xkb. I've never used the former (command), but have used the latter (xorg config, you're editing config files), fumblingly, to some extent, to get the "extra" keys on various internet/ media/fancy keyboards working over the years. For the xmodmap solution, after a quick read of the manpage and a google, you'd presumably configure your desktop (I know and can tell you how to do it for kde/plasma...) to run a short script on X startup (if starting your desktop session from a text login using startx or similar, as I do) or login (if using a *DM based graphical login) that would do something like this: xmodmap -e "keycode 91 = Delete" After I run that manually from a terminal window here, pressing the keypad delete key now gives me Delete for the keysym, and the hex 7f lookup string in xev: KeyPress event, serial 40, synthetic NO, window 0x2000001, root 0x4c0, subw 0x0, time 107201547, (1,179), root:(963,1284), state 0x0, keycode 91 (keysym 0xffff, Delete), same_screen YES, XLookupString gives 1 bytes: (7f) "" XmbLookupString gives 1 bytes: (7f) "" XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x2000001, root 0x4c0, subw 0x0, time 107201647, (1,179), root:(963,1284), state 0x0, keycode 91 (keysym 0xffff, Delete), same_screen YES, XLookupString gives 1 bytes: (7f) "" XFilterEvent returns: False So it looks like that should work, but of course note that it will affect the key in a similar way when used with other apps, not just pan. Also note that with the mapping above, numlock/shift no longer changes the mapping -- it's the Delete keysym regardless, now, so I couldn't use the numlock to switch it to numeric entry mode as I no longer have a decimal point key there! Also, note that (based on googling) you'll likely have to rerun that script/command after returning from suspend or hibernate apparently resets it to the default. Editing the xkb tables (as I've done, but fumblingly, before, here, so I won't attempt to explain how) should prevent that issue, but note that you'll probably have to reedit them if you update or otherwise reinstall the xkb package. Another alternative is to run something like sxhkd, the "simple X hotkey daemon". When this daemon is run it sets itself up to listen to the xinput stream (both keyboard and mouse) and will act on anything it sees that it has been configured for. I use it here for a number of things, including hotkey chaining, and triggering various actions on the higher mouse button events[1]. The nice thing about something like sxhkd, other than its rather extreme flexibility in what you can configure it to do based on input events, is the fact that it only does them while it's running, and with the appropriate scripts, conditionally depending on what app is active. So for sure you can configure sxhkd to intercept the KP_Delete key events and emit the delete key instead, and it'll only do that as long as you want it to -- kill sxhkd when you're done and everything will be back to default. And with the appropriate scripts (I've coded my own here and can post them if necessary), you can further condition the commands sxhkd to for example only emit the delete sym and string when the keypad delete key is pressed, if pan is the active/focused application. Tho configuring is a matter of editing text files, optionally with scripting, and while thus extremely powerful in what it allows you to do, will very likely scare away users who want a nice GUI to configure things with and are scared of the commandline and text-based config files. --- [1] Upper mouse button events: 1-3 are standard left/middle/right, 4,5 are now standard vertical scroll, 6,7 are very commonly but not quite as standardized horizontal scroll, and above that isn't well standardized, but I have a touchpad and run the xf86-input-mtrack driver, configured to emit the higher 8-20 mouse button events on various gestures such as pinch, rotate, and three and four finger swipes up/down/left/right. So the driver emits those events, but apps don't know how to interpret them, and I need another layer to listen for those events and emit the appropriate keystrokes or run the appropriate commands, either globally or based on what app is active, to convert the upper mouse button events into actual actions. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users