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
