Benjamin.Riefenstahl@[...].de said:
>  Complexity of the implementation.  Each such nit increases the size
>    of the implementation.  And I am talking primarily about the size of
>    the source code, which has to be maintained, not so much the size of
>    the binary

Also, the proposed [tk keypadevents] has to be implemented on multiple
platforms, because with it, KP_* events have to be translated to their
non-keypad counterparts; Windows keyboard events have to be translated
(or not) to KP_* according to whether KF_EXTENDED was present, and I
haven't a clue *what* has to happen on the Mac.

Another issue that I have is that on international keyboards, the keypad
callouts may be different.  Windows is capable of associating KF_EXTENDED
with any symbol, to flag that it was typed on the "extended" part of the
keyboard.  That raises the spectre of possible keys on the Windows keyboard
for which no corrsesponding X keysym exists.  Again, I'm not sure I can
figure out *what* to do with that one.

The idea that KF_EXTENDED == Mod4 is at least simple.

In short, implementing George's proposal is beyond my expertise.
If the TIP is amended to use [tk keypadevents], I shall no longer
sponsor it nor lead its implementation.  

>  Complexity of use.  Such settings are global resources.  One library
>    package can not decide which mode to use for the whole application.
>    So in the end every package that needs this (even single-platform
>    packages) has to bind to both keysyms.  Although one could argue
>    that portable packages need to do this anyway with the current TIP.

I'm with Benny on this one, too.

As far as I can tell, a [tk keypadevents] command wouldn't really make
life much easier for anyone.

Authors of widget libraries won't own the settings, and so won't be
able to depend on <Return>  versus <KP_Enter> - and will therefore have
exactly as much complexity to deal with as they do today.  They are the
users of the lion's share of bindings.

Authors of applications often create only a few bindings - the default
bindings on the widgets are almost always The Right Thing.  I would hope
that on "green field" projects, nobody will undertake the documentation
nightmare of "you must press the Enter key on the keyboard, not the one
on the numeric pad".

Maintainers of legacy applications still have to go grepping for
binding strings anyway.

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
kennykb@[...].com           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core