KP_Enter on Win -> patch
Wolf Grossi
I'd like to submit a patch for the module tkWinX.c, function GetState,
solving the problem of distinguishing between Return and KP_Enter on
Windows. It makes <KP_Enter> to be recognized as <Mod4-Return> on
Windows, thanks to Kevin Kenny for the hint.
How do I have to proceed to get the patch, which has been verifyed,
implemented into the next Tk Release?
Additionally, I need to have a StarKit of this patched Version - whom do
I have to contact to archieve this task?
Thanks for reading and hints,
Wolf
Jeff Hobbs
> I'd like to submit a patch for the module tkWinX.c, function GetState,
> solving the problem of distinguishing between Return and KP_Enter on
> Windows. It makes <KP_Enter> to be recognized as <Mod4-Return> on
> Windows, thanks to Kevin Kenny for the hint.
But is it also recognized as just Return when Mod4-Return isn't defined
for backwards compatability?
> How do I have to proceed to get the patch, which has been verifyed,
> implemented into the next Tk Release?
You have to submit it to SF for review (to Tk Patches section).
> Additionally, I need to have a StarKit of this patched Version - whom do
> I have to contact to archieve this task?
If you have a license for Tcl Dev Kit, we could give you an updated
base kit, but that presumes it gets into the 8.4 core first.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Wolf Grossi
> Wolf Grossi wrote:
>
>> I'd like to submit a patch for the module tkWinX.c, function GetState,
>> solving the problem of distinguishing between Return and KP_Enter on
>> Windows. It makes <KP_Enter> to be recognized as <Mod4-Return> on
>> Windows, thanks to Kevin Kenny for the hint.
>
>
> But is it also recognized as just Return when Mod4-Return isn't defined
> for backwards compatability?
>
Yes, I've verifyed that.
If just <Return> is bound, *both* keys Return and Enter are recognized
by the <Return> binding.
>> How do I have to proceed to get the patch, which has been verifyed,
>> implemented into the next Tk Release?
>
>
> You have to submit it to SF for review (to Tk Patches section).
>
>> Additionally, I need to have a StarKit of this patched Version - whom
>> do I have to contact to archieve this task?
>
>
> If you have a license for Tcl Dev Kit, we could give you an updated
> base kit, but that presumes it gets into the 8.4 core first.
>
Ahm, I'm not using Tcl Dev Kit (yet?), I'm using Starpack/Starkit as
decribed in mini.net/tcl/3663
Thanks,
Wolf
Kevin Kenny
> I'd like to submit a patch for the module tkWinX.c, function GetState,
> solving the problem of distinguishing between Return and KP_Enter on
> Windows. It makes <KP_Enter> to be recognized as <Mod4-Return> on
> Windows, thanks to Kevin Kenny for the hint.
>
> How do I have to proceed to get the patch, which has been verifyed,
> implemented into the next Tk Release?
Wolf,
Upload the patch at the Tk Patch Manager:
https://sourceforge.net/tracker/?atid=312997&group_id=12997
(Oh wait, I see that you did already. Smart fellow.)
I think that this change, small as it is, should get a TIP.
I'd be happy to sponsor the TIP if you'd like to write it. If
you'd rather that I write it, e-mail me.
--
73 de ke9tv/2, Kevin
Donald Arseneau
> But is it also recognized as just Return when Mod4-Return isn't defined
> for backwards compatability?
Doesn't that just "happen"?
Donald Arseneau as...@triumf.ca
Jeff Hobbs
>>But is it also recognized as just Return when Mod4-Return isn't defined
>>for backwards compatability?
>
> Doesn't that just "happen"?
Usually yes, but if you haven't specifically tested for it, anything
can happen.
Benjamin Riefenstahl
Wolf Grossi <Go2De...@magro-soft.com> writes:
> I'd like to submit a patch for the module tkWinX.c, function
> GetState, solving the problem of distinguishing between Return and
> KP_Enter on Windows. It makes <KP_Enter> to be recognized as
> <Mod4-Return> on Windows, thanks to Kevin Kenny for the hint.
While this makes a distinction, would it not be The Right Thing to do,
to actually generate a <KP_Enter> keysym in this situation? And add
the other keypad keys while we're at it? I'd say that would fix a bug
(or limitation) on Windows. Or am I misunderstanding something? Is
that too hard to implement?
I'd really prefer that people be able to use the same Tcl code on all
platforms, instead of having to check an additional piece of
documentation about platform abberrations.
benny
Kevin Kenny
> While this makes a distinction, would it not be The Right Thing to do,
> to actually generate a <KP_Enter> keysym in this situation? And add
> the other keypad keys while we're at it? I'd say that would fix a bug
> (or limitation) on Windows. Or am I misunderstanding something? Is
> that too hard to implement?
>
> I'd really prefer that people be able to use the same Tcl code on all
> platforms, instead of having to check an additional piece of
> documentation about platform abberrations.
It's not hard to implement, but exceedingly likely to break existing
deployed code. Programmers on Windows are expecting that the
key in question will generate <Return>, and code that binds
<Return> without also binding <KP_Enter> would suddenly stop working.
What's more, I was of two minds about doing this at all, because
it violates the Microsoft User Interface Guidelines, which
explicitly state that if two keys have the same callout (keyboard
<Enter> vs numeric <Enter>, left <Shift> vs right <Shift>, etc.)
they must have the same functionality. See
http://msdn.microsoft.com/library/en-us/dnwue/html/ch05c.asp
The rationale behind the rule is that it is much easier to document
the user interface, rather than constantly having to warn the user
to distinguish among the Enter key on the keyboard and that on
the numeric pad.
Moreover, not all keyboards even HAVE the key
in question. I'm typing this on a laptop which has no numeric
pad on its keyboard. While it has a mode that allows
the right half of the conventional keyboard to function as a
sixteen-key numeric pad, that function does not cause the <Enter>
to be distinguished in any way. An application that depends on
the existence of <KP_Enter> will be inaccessible to me on this
machine.
The Mod4 compromise serves both the Unix and Windows communities,
and indeed one can use the same code on both platforms.
A Windows application that binds only <Enter> will behave as
expected on Windows, and (alas!) Unix users are quite used to
applications that fail to recognize <KP_Enter>.
A Unix application that binds both <Enter> and <KP_Enter> to the
same functionality - good practice in any case - will continue to
behave as expected on Windows. On Windows, it will never see
<KP_Enter>, but that's harmless. (Note that wherever Tk binds
<Enter> itself, it also binds <KP_Enter> and vice versa - if you
find an exception, report it as a bug!)
A Unix application that needs to distinguish the keys can still
run on both platforms by binding both <KP_Enter> and
<Mod4-Enter>. In this case, the programmer needs to be aware that
the application is violating the MS User Interface Guidelines
and will be seen as noncompliant.
Benjamin Riefenstahl
Kevin Kenny <ken...@acm.org> writes:
> It's not hard to implement, but exceedingly likely to break existing
> deployed code. Programmers on Windows are expecting that the key in
> question will generate <Return>, and code that binds <Return>
> without also binding <KP_Enter> would suddenly stop working.
"Stop working" seems a bit harsh for me. It's not like the
application can not be used any more at all. Than it should be very
simple to add that binding. Thirdly the application can still be run
with the old version of Tcl if needed. I don't see how this change
can cause serious problems.
As a programmer I expect a new version of Tcl to fix bugs, and I
expect that sometimes I will need to change my code because I have
relied on a bug explicitly or implicitly.
> What's more, I was of two minds about doing this at all, because it
> violates the Microsoft User Interface Guidelines, which explicitly
> state that if two keys have the same callout (keyboard <Enter> vs
> numeric <Enter>, left <Shift> vs right <Shift>, etc.) they must
> have the same functionality.
But the Tcl policy has usually been to let the application programmer
or the user decide such issues. Is it really Tk's job to do this?
This is good stuff for the documentation or for a book, or for a
collection of best-practices, but I wouldn't put it into the framework
in this way.
> Moreover, not all keyboards even HAVE the key in question. [...]
Of course not. Why is that relevant? Not all keyboards have all
keys. That doesn't mean we only support those that are common on all
systems. I'd guess that few other systems have Mod4-Return (yet)
either. I'm sure any serious programmer knows that not all systems
have a keypad.
> An application that depends on the existence of <KP_Enter> will be
> inaccessible to me on this machine.
An application that requires Control-\ is inaccessible on my machine
now. So?
I understand your arguments but I don't find them convincing. I think
compatibility with the X11 version of Tcl (which would continue to
behave differently on the same hardware) and the principle of least
surprise (for the programmer) are much more important.
benny
Donald Arseneau
[Good points about <Return> and <KP_Enter>, except he consistently
misspells <Return>]
Be very very careful about this easy mistake, because <Enter> *is*
a legal binding.
Donald Arseneau as...@triumf.ca
Kevin Kenny
> [Good points about <Return> and <KP_Enter>, except he consistently
> misspells <Return>]
>
> Be very very careful about this easy mistake, because <Enter> *is*
> a legal binding.
Egg is on my face. Of course <Return> is what I intended. In my
code, I generally spell it <Key-Return> so that if I commit the
error and make it <Key-Enter>, it'll be a bad binding and get caught
at initialization time. I commend that spelling to everyone as
a best practice, since even the experts fall into this trap from
time to time.
Bruce B Hartweg
Kevin Kenny wrote:
good advice, It never occured to me to overspecify that case just to
catch ther
error (which I am occasionally bitten by).
Thanks,
Bruce
lvi...@yahoo.com
According to Wolf Grossi <Go2De...@magro-soft.com>:
:Ahm, I'm not using Tcl Dev Kit (yet?), I'm using Starpack/Starkit as
:decribed in mini.net/tcl/3663
When the patch makes it into the Tk distribution, then a request to
the starkit mailing list
http://www.equi4.com/mailman/listinfo/starkit
requesting a new official version of tclkit can be sent.
--
<URL: http://wiki.tcl.tk/ > <URL: http://www.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
"@magro-soft.com >
Wolf