This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: On linux, numeric pad input is ignored when numlock off
Type: enhancement Stage: resolved
Components: IDLE Versions: Python 3.7, Python 3.6
process
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: terry.reedy Nosy List: rhettinger, terry.reedy
Priority: low Keywords:

Created on 2004-11-27 21:37 by netvigator, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (13)
msg23350 - (view) Author: Rick Graves (netvigator) Date: 2004-11-27 21:37
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.
3. Open gedit, type in garbage, use direction keys on
numpad to move around.
4. 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.

msg23351 - (view) Author: Rick Graves (netvigator) Date: 2004-11-27 21:50
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.  
msg23352 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-12-19 21:44
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.
msg23353 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2004-12-19 23:13
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/
msg23354 - (view) Author: Rick Graves (netvigator) Date: 2004-12-20 06:14
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 
msg23355 - (view) Author: Johannes Gijsbers (jlgijsbers) * (Python triager) Date: 2004-12-20 12:59
Logged In: YES 
user_id=469548

OP = opening poster. So yes, the ball is in your court. :)
msg23356 - (view) Author: Rick Graves (netvigator) Date: 2004-12-25 00:32
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 
msg23357 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2004-12-30 02:54
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...  :-)
msg82122 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-02-14 21:57
Confirmed in trunk, the <KP_Up> (80) events show in a terminal if one
adds some print-based debug help.
msg86363 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-04-23 11:58
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.
msg86364 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-04-23 12:23
> 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()
msg222771 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-07-11 18:10
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.
msg370912 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-06-07 21:37
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.
History
Date User Action Args
2022-04-11 14:56:08adminsetgithub: 41237
2020-06-07 21:37:55terry.reedysetstatus: open -> closed

nosy: - kbk, jlgijsbers, netvigator, ajaksu2, gpolo
messages: + msg370912

resolution: accepted -> third party
stage: test needed -> resolved
2017-06-20 19:44:33terry.reedysetassignee: terry.reedy
versions: + Python 3.6, Python 3.7, - Python 2.7, Python 3.4, Python 3.5
2014-07-11 18:10:51terry.reedysetpriority: normal -> low

type: behavior -> enhancement
assignee: kbk -> (no value)

title: input from numeric pad always dropped when numlock off -> On linux, numeric pad input is ignored when numlock off
nosy: + terry.reedy
versions: + Python 3.4, Python 3.5, - Python 3.1, Python 3.2
messages: + msg222771
2010-08-19 18:37:15BreamoreBoysetversions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6
2009-04-23 12:23:59gpolosetmessages: + msg86364
2009-04-23 11:58:57gpolosetmessages: + msg86363
2009-04-22 16:03:45ajaksu2setnosy: + gpolo
2009-02-14 21:57:28ajaksu2setnosy: + ajaksu2
stage: test needed
type: behavior
messages: + msg82122
versions: + Python 2.6, - Python 2.3
2004-11-27 21:37:55netvigatorcreate