Author: Wolfgang Großbauer <[email protected]> Author: Kevin Kenny <[email protected]> State: Final Type: Project Vote: Done Created: 20-Sep-2003 Post-History: Discussions-To: news:comp.lang.tcl Tcl-Version: 8.5 Tk-Ticket: 797404
This TIP proposes that the "extended keys" on a Windows keyboard be
Most US keyboards on Windows systems have two keys bearing the label,
'Enter'. The Tk system generates the events,
The solution that has been chosen supports the greatest possible backward compatibility. What is proposed is that 'tkWinX.c' will examine the KF_EXTENDED bit in the keyboard state (passed as lParam to the GetState function) and map it as modifier 4. (Modifiers 1 through 3, respectively, refer to the Num Lock, Alt, and Scroll Lock keys.) An alias shall be added so that Extended may be used in place of Mod4.
This change has little if any impact on existing Windows code, since
modifier 4 is not generated on Windows today. A binding to
Existing Unix code that binds
Unix code that has distinct bindings for
Although the immediate purpose of the change is to deal with the
numeric Enter key, the effect of the change will be to deal with
the rest of the numeric pad the same way; rather than generating
events such as
The changes require to implement an earlier version of this proposal can be obtained from SourceForge as Tk Patch #797404.
Summary of Discussion
This change has been discussed extensively on the tcl-core mailing list (http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/1791694 and several following threads) and the comp.lang.tcl newsgroup http://groups.google.com/[email protected] .
The chief proposed alternative to the use of modifier 4 was to modify
tkWinX.c so that the Enter key on the numeric pad would
generate the same
One proposed workaround was to have a default all binding for
The open issue of what to do about the problem on the Macintosh platform remains. The authors of this TIP are too ignorant of Macintosh programming to address it.
This proposal has engendered a fair amount of controversy, as may be seen in the two threads of messages beginning from http://aspn.activestate.com/ASPN/Mail/Message/1811543 and http://aspn.activestate.com/ASPN/Mail/Message/1820298 .
More recent additional discussion is archived at http://aspn.activestate.com/ASPN/Mail/Message/2032516 . Vince Darley summarizes it:
For example, there is Benny's suggestion to your all counterexample that the counterexample really contains a bug, since any key-binding ought to have ;break to prevent exactly that problem. Do we guarantee backwards compatibility even with buggy code?
Second there is the suggestion that if you really don't want the all binding to fire if another binding has triggered, you could actually check for that manually (scan the bindtags list, etc). This would reduce the backwards incompatibility of an overall cleaner solution to effectively nothing.
Third, the TIP contains no mention of what the result of this TIP is on the x-platform Tk developer. That they must now have this:
bind ... <Return> "pressReturn" bind ... <KP_Enter> "pressEnter" ; # only useful on Unix bind ... <Extended-Return> "pressEnter" ; # only useful on Windows
i.e. rather than making their life easier, it has been made more complex! (In fact the TIP as a whole seems to have a bias against anyone even considering writing the same application on multiple platforms, which seems v. odd for Tk)
Copyright © 2003, 2004 by Kevin B. Kenny. All rights reserved.
Permission to use this document in accordance with the terms of Open Publication License http://www.opencontent.org/openpub/ is herewith granted.