On linux, numeric pad input is ignored when numlock off

[netvigator]

BPO	1074333
Nosy	@rhettinger, @terryjreedy

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/terryjreedy'
closed_at = <Date 2020-06-07.21:37:55.519>
created_at = <Date 2004-11-27.21:37:55.000>
labels = ['expert-IDLE', 'type-feature', '3.7']
title = 'On linux, numeric pad input is ignored when numlock off'
updated_at = <Date 2020-06-07.21:37:55.514>
user = 'https://bugs.python.org/netvigator'

bugs.python.org fields:

activity = <Date 2020-06-07.21:37:55.514>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = True
closed_date = <Date 2020-06-07.21:37:55.519>
closer = 'terry.reedy'
components = ['IDLE']
creation = <Date 2004-11-27.21:37:55.000>
creator = 'netvigator'
dependencies = []
files = []
hgrepos = []
issue_num = 1074333
keywords = []
message_count = 13.0
messages = ['23350', '23351', '23352', '23353', '23354', '23355', '23356', '23357', '82122', '86363', '86364', '222771', '370912']
nosy_count = 2.0
nosy_names = ['rhettinger', 'terry.reedy']
pr_nums = []
priority = 'low'
resolution = 'third party'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1074333'
versions = ['Python 3.6', 'Python 3.7']

[netvigator]

The behaviour of the direction keys on the numpad is
inconsistent when numlock is turned off.
Home/End/PgUp/PgDn and the arrow keys work fine in some
applications (gedit), but do not work in Python's idle.
By not work, I mean: input is silently dropped.

How reproducible:
Always

Steps to Reproduce:

1. Turn off numlock.
2. Open gedit, type in garbage, use direction keys on
   numpad to move around.
3. Open idle, type in garbage, attempt to use direction
   keys on numpad to move around. It fails.

Actual Results: Intense frustration for people who
have been using the numeric keypad as direction keys
for decades!

Expected Results: When numlock is off, the direction
keys on the numpad should function in the same manner
as the dedicated direction keys.

I am reporting this for Python 2.3, but I had exactly
the same problem in Python 2.2.

This problem has also been reported to RedHat, see

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600.

[netvigator]

Logged In: YES
user_id=1167414

In RedHat bugzilla, this problem was reported for fedora
under x86_64. I have been having the problem on i386 using
CentOS-3, which is similar to RHEL 3. So the problem seems
to apply across Linux architectures, but not across
platforms. It may be a RedHat problem across architectures.

[rhettinger]

Logged In: YES
user_id=80475

Kurt, as far as I can tell, there is nothing in Tkinter that
gives us any control over this. If you concur, please mark
this as 3rd party and/or platform specific and close it.

[kbkaiser]

Logged In: YES
user_id=149084

Yes, if OP wants to pursue it, he should take it up with the
Tk people: http://tcl.sourceforge.net/

[netvigator]

Logged In: YES
user_id=1167414

Yes, if OP wants to pursue it, he should take it up with the
Tk people: http://tcl.sourceforge.net/

1. Who is OP?

2. Is this ball in my court or someone else's?

Thanks,

netvigator aka Rick Graves

[jlgijsbers]

Logged In: YES
user_id=469548

OP = opening poster. So yes, the ball is in your court. :)

[netvigator]

Logged In: YES
user_id=1167414

I posted the "bug" on the Tk list as suggested. Today I got this:

begin quote

Comment By: Jeffrey Hobbs (hobbs)
Date: 2004-12-24 11:25

Message:
Logged In: YES
user_id=72656

This is not a bug, but rather just that Tk differentiates
between the regular arrow up and keypad up on some systems,
depending on how their system keymaps operate. The first is
<Up> and the second is <KP_Up> on Linux, but both are <Up>
on Windows. This has always been the case for KP_Enter as
well. The fact that Windows doesn't separate these is by
design, but has also caused people to want them separated
(see TIP http://www.tcl.tk/cgi-bin/tct/tip/158.html).

IOW, the bindings should be on <Up> and <KP_Up> if they are
to be considered equivalent in an app. This is best handled
by using virtual events (like <<Up>>) and adding the
specific event names that you want to apply to it. Please
filter this back to the other reports.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1090719&group_id=12997

end quote

Would someone please either reopen this or let me know what my
next step should be.

Thanks,

Rick

[kbkaiser]

Logged In: YES
user_id=149084

OK, thanks for the leg work. I'll take a further look.

My keyboards are IBM Model M SpaceSavers. I don't
do keypads... :-)

[devdanzin]

Confirmed in trunk, the <KP_Up> (80) events show in a terminal if one
adds some print-based debug help.

[gpolo]

Unfortunately this is not that easy for us, while we could add some code
like this:

import Tkinter

text = Tkinter.Text()
text.event_add("<<Up>>", "<Key-Up>")
text.event_add("<<Up>>", "<Key-KP_Up>")
text.bind_class("Text", "<<Up>>", text.bind_class("Text", "<Key-Up>"))
text.pack()
text.mainloop()

it won't work as most would expect. When numlock is on, it would still
move one line up. We could change it to fix this problem, but then we
would be using tk::TextUpDownLine which is marked as unsupported
(basically everything that could help us in such situations is marked as
unsupported).
I will be asking someone about all these unsupported commands.

[gpolo]

When numlock is on, it would still
move one line up. We could change it to fix this problem, but then we
would be using tk::TextUpDownLine which is marked as unsupported
(basically everything that could help us in such situations is marked as
unsupported).

Ah yes, here is something that would do what we wanted (for "up" only):

import Tkinter

def my_up(event):
    widget = event.widget
    if event.keysym == 'KP_Up' and event.state & 16:
        widget.tk.call('tk::TextInsert', widget, event.char)
        return "break"
    pos = widget.tk.call('tk::TextUpDownLine', widget, -1)
    widget.tk.call('tk::TextSetCursor', widget, pos)

text = Tkinter.Text()
text.event_add("<<Up>>", "<Key-Up>")
text.event_add("<<Up>>", "<Key-KP_Up>")
text.bind_class("Text", "<<Up>>", my_up)
text.pack()
text.mainloop()

[terryjreedy]

I verified that this issue does not affect Windows. What about Mac? A patch might best be system-specific in only being active on systems that need it.

The lack of complaints other than by one person suggests that it is not a high priority among linux users -- or that they are all resigned to flakey behavior, or that some other linux apps also do not recognize numlock-off keypad keys.

[terryjreedy]

Summary: (Graves, msg23356, 2004-12-24) tk event for keypad keys depends on system keymap. Windows: numlock off, keypad up (8) is <up>. Linux: same is <kp-up> and Text does *not* see this as <up>
(Polo, msg86364, 2009-04-23) Workaround is to capture both events and tk:call multiple upsupported internal tk functions.

In the absence of more contemporary complaints by Linux users, closing.

[hsantanna]

There is any way for making the Home key from keypad (KP_Home) to work just like the normal Home key with IDLE shell/editor?

And the same to KP_End, KP_Prior (PageUp) and KP_Next (PageDown).

The KP_Home, KP_End, KP_Prior and KP_Next keys doesn't work with IDLE on Linux (I didn't test it on MS Windows).

The expected behavior is the KP_Home to move the keyboard cursor to the begin of the line and the KP_End to move to the end of the line, just like Home and End keys.

Ctrl + KP_Home should move to the begin of the file and Ctrl + KP_End should move to the end of the file.

Shift modifier should be used to select text together with any of those keypad keys. But it depends on keyboard layout, for some (or most) keyboard layouts on Linux, Shift modifier will return a number when used together with keypad keys. For my keyboard layout Shift only modify the keypad keys if NumLock is active, so the expected behavior is that it triggers text selection.

Those expected behaviors works for almost any non TKinter applications on modern Linux desktops, ie, works on GTK or QT based software.

As already discussed for this bug, TK will not change it's own default behavior, since this is the desired behavior for some use cases.

That said, I ask, please, that this bug is re-opened
(or ask me and I will open a new bug for this).