When adding GenericEvent they increased the value of LASTEvent in X.h.
Tk wasn't designed to handle this change, so in the future you will
probably find that your existing versions of Tk won't run with a newer
X, without errors. The X.org change has also created a binary
incompatibility.
The bug is documented in the Tk tracker here:
http://sourceforge.net/tracker/index.php?func=detail&aid=2010422&group_id=12997&atid=112997
This change has already caused problems for some Gentoo users. Gentoo
has a patch, though it's believed by some Tk developers that a fix that
Gentoo is using isn't ideal. Some other X.org users are experiencing
problems as well.
Some rethought of the tk/generic/tkBind.c code is needed in order to
decouple Tk from protocol changes. In addition to that tk/generic/tk.h
makes assumptions about the LASTEvent when creating virtual events. See
Joe English's comments in the bug tracker for further information.
Hopefully this will be resolved soon in new releases of Tk.
If you have ideas that could result in a better design for the event and
virtual event code, then please share your ideas and code. Hopefully
the path of least resistance will be found.
I decided to post this message because more people are experiencing the
problem, and this message may save some time and frustration.
George
More precisely: all existing source distributions of Tk
will fail to run if they are compiled against new X.org headers.
Existing binary versions should be OK -- we hope -- as long
as they were compiled against old X11 headers, i.e., any
version from X11R3 (1988) up to and including X11R7.3 (2007).
> The X.org change has also created a binary incompatibility.
I'm not sure that this is the case. As far as I can see,
existing binaries -- wish, libtk, and any extensions --
should be OK. The problem only manifests if Tk is compiled
against X11 headers from the xproto-7.0.13 release.
> The bug is documented in the Tk tracker here:
> http://sourceforge.net/tracker/index.php?func=detail&aid=2010422&group_id=12997&atid=112997
>
> This change has already caused problems for some Gentoo users.
Current NetBSD users may also be affected. The problem
will undoubtedly start showing up in other distros as well.
> Gentoo
> has a patch, though it's believed by some Tk developers that a fix that
> Gentoo is using isn't ideal. Some other X.org users are experiencing
> problems as well.
>
> Some rethought of the tk/generic/tkBind.c code is needed in order to
> decouple Tk from protocol changes. In addition to that tk/generic/tk.h
> makes assumptions about the LASTEvent when creating virtual events. See
> Joe English's comments in the bug tracker for further information.
>
> Hopefully this will be resolved soon in new releases of Tk.
>
> If you have ideas that could result in a better design for the event and
> virtual event code, then please share your ideas and code. Hopefully
> the path of least resistance will be found.
>
> I decided to post this message because more people are experiencing the
> problem, and this message may save some time and frustration.
--Joe English
I suspect that they'll be OK as long as they are compiled *and linked*
against an old enough Xlib (i.e. one that is from last year or before).
The constraint is that Xlib has to declare to the Xserver that it's too
old to support GenericEvents. If it's newer than that, there's no way to
prevent the delivery of a GenericEvent to Tk; if it arrives right now,
we end up with an attack of the nasal demons.
Looking at how to fix this, it's a hard situation. The problem is that
we need custom event numbers, and they now clash with standard event
numbers. We have to change, and that modifies the ABI though code which
doesn't refer to any of our synthetic events should be OK. The things to
grep extension source for (to determine if it is effected) are:
VirtualEvent, ActivateNotify, DeactivateNotify, MouseWheelEvent,
TK_LASTEVENT
If the extension doesn't refer to those, it should be fine. (Thankfully,
it seems that there were no alterations to the set of event mask bits.)
(Tk itself will need more changes; it made assumptions about the value
of the X11 LASTEvent macro. Can't be helped.)
Donal.