| 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) *  |
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) * |
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) *  |
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 and the second is <KP_Up> on Linux, but both are 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 and <KP_Up> if they are to be considered equivalent in an app. This is best handled by using virtual events (like <>) 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) * |
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) * |
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) * |
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("<>", "") text.event_add("<>", "<Key-KP_Up>") text.bind_class("Text", "<>", text.bind_class("Text", "")) 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) * |
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("<>", "") text.event_add("<>", "<Key-KP_Up>") text.bind_class("Text", "<>", my_up) text.pack() text.mainloop() |
|
|
| msg222771 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
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) * |
Date: 2020-06-07 21:37 |
| Summary: (Graves, , 2004-12-24) tk event for keypad keys depends on system keymap. Windows: numlock off, keypad up (8) is . Linux: same is and Text does *not* see this as (Polo, , 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. |
|
|