[TCLCORE] Regarding Tk ticket 9e31fd944934e269

[Christian Werner]

Ticket http://core.tcl.tk/tk/info/9e31fd944934e269 introduces a series of rather huge
patches where the most prominent are

http://core.tcl.tk/tk/info/a9d7c4da2cb869e1 core-8-5-branch
http://core.tcl.tk/tk/info/8a96bfd047696f59 core-8-6-branch

which eliminate the X11 symbol None (and ControlMask) all through out the entire Tk
source tree. The reason seems to be according to the aforementioned ticket the latest
Windows SDK for causing problems when building tkinter due to adding structure fields
of the same name in some (new?, internal?) structs of Windows (which aren't in use by
Tcl and Tk today, anyway).

That is of course a *** POTENTIAL INCOMPATIBILITY *** affecting only Win32. All external
extensions now have to deal with POSIX vs. Win32 regarding the None symbol when used with
not unusual X11-isms. IMO this is bad practice.

Worse is, that simple, documented things like

XSetClipMask(display, gc, None);

now are written in all parts of the (otherwise canonical) Tk source code as

XSetClipMask(display, gc, 0);

which now needs extra brain cycles when reading the XSetClipMask(3) man page due to
keeping in mind that None happens to be defined to 0L.

And worst (at least for me) is, that this change happened out of the blue, without
a branch for testing and further review before being committed into critical branches.
Or should that stuff have needed even to be TIP'ed?

Regards,
Christian









_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Brian Griffin]

On Dec 25, 2018, at 3:28 PM, Christian Werner <Christia...@t-online.de> wrote:

Ticket http://core.tcl.tk/tk/info/9e31fd944934e269 introduces a series of rather huge
patches where the most prominent are

 http://core.tcl.tk/tk/info/a9d7c4da2cb869e1  core-8-5-branch
 http://core.tcl.tk/tk/info/8a96bfd047696f59  core-8-6-branch

which eliminate the X11 symbol None (and ControlMask) all through out the entire Tk
source tree. The reason seems to be according to the aforementioned ticket the latest
Windows SDK for causing problems when building tkinter due to adding structure fields
of the same name in some (new?, internal?) structs of Windows (which aren't in use by
Tcl and Tk today, anyway).

That is of course a *** POTENTIAL INCOMPATIBILITY *** affecting only Win32. All external
extensions now have to deal with POSIX vs. Win32 regarding the None symbol when used with
not unusual X11-isms. IMO this is bad practice.

Worse is, that simple, documented things like

  XSetClipMask(display, gc, None);

now are written in all parts of the (otherwise canonical) Tk source code as

  XSetClipMask(display, gc, 0);

which now needs extra brain cycles when reading the XSetClipMask(3) man page due to
keeping in mind that None happens to be defined to 0L.

And worst (at least for me) is, that this change happened out of the blue, without
a branch for testing and further review before being committed into critical branches.
Or should that stuff have needed even to be TIP'ed?

Seems odd to me that a, at the least, a Tk_None or similar macro should have been defined to replace None, and defined as needed/appropriate per platform.

Other then that, I understand the unfortunate need to make a change.

-Brian

[Gregor Cramer]

On Wednesday 26 December 2018 00:28:25 Christian Werner wrote:
> Ticket http://core.tcl.tk/tk/info/9e31fd944934e269 introduces a series of

> rather huge patches where the most prominent are...

The Tk library is developed for X11, and ported to Windows. This patch would
ignore this fact, so replacing the X11 constants "None" and "ControlMask"
seems to be improper for me. IMO it's clear that Windows needs a special
handling for such conflicts, but this patch is introducing a special handling
for X11 developing (because X11 is defining "None" and "ControlMask"). I
think that this *patch* requires a TIP, and a voting of all members, whether
this reversal of programming style (Windows programming instead of X11
programming) is desired. I'm astonished that this ticket of Windows
programmers is solved in such a way - reversing the programming style -,
because the established way, solving the special Windows problems, has been
ignored. I like to state that X11 is used on both platforms Mac OS and
Linux/UNIX, and Windows is definitively not leading (not in Tk). Moreover this
*patch* is complicating further development, because in general an X11
developer will not remember this special Windows handling, and the Tk library
is based on X11.

Gregor