Tk Toolkit

Patch partially applied to core-8-4 branch (generic/tk.h changes only).

This is enough to make all branches compile and run against new libX11
headers; more future-proofing TBDL.

Revised version of genericevent.patch (removed timebomb code, compiles
without warnings) committed to HEAD, backported to core-8-5-branch.

Because it should be Tcl_Panic("Wild GenericEvent; panic!
(extension=%d,evtype=%d)",xgePtr->extension, xgePtr->evtype);

The comma was missing with gcc-4.3.1.

while attempting to test genericevent.patch for our distro, I found that tk
would not build. It is failing at this point:
gcc -c -O2 -march=pentium4 -pipe -pipe -Wall -Wno-implicit-int -fPIC
-I/usr/src/tk8.5.3/unix/../unix -I/usr/src/tk8.5.3/unix/../generic
-I/usr/src/tk8.5.3/unix/../bitmaps -I/usr/src/tcl8.5.3/generic
-I/usr/src/tcl8.5.3/unix -DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\"
-DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tk\ 8.5\"
-DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1
-DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_GETATTR_NP=1
-DGETATTRNP_NOT_DECLARED=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_SHLIB_EXT=\".so\"
-DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -D_LARGEFILE64_SOURCE=1
-DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1
-DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1 -DHAVE_SYS_TIME_H=1
-DTIME_WITH_SYS_TIME=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1
-DHAVE_PW_GECOS=1 -DHAVE_XSS=1 -DHAVE_LIBXFT=1 -DHAVE_XFT=1
-DTCL_NO_DEPRECATED -DUSE_TCL_STUBS
/usr/src/tk8.5.3/unix/../unix/tkUnixEvent.c
/usr/src/tk8.5.3/unix/../unix/tkUnixEvent.c: In function
'TransferXEventsToTcl':
/usr/src/tk8.5.3/unix/../unix/tkUnixEvent.c:297: error: expected ')' before
'xgePtr'
/usr/src/tk8.5.3/unix/../unix/tkUnixEvent.c:294: warning: unused variable
'xgePtr'
make: *** [tkUnixEvent.o] Error 1

Building without any patch or with tk-lastevent.patch completes with no
errors.

With even more reading, it seems that GenericEvents should only get
delivered if using an XCB-enabled Xlib. I think. If that's true (the facts
are very thin on the ground it seems) *and* we're not built with one of
these XCB Xlibs (don't know what's going on there) then the suggested patch
will work. But I think the extended version of it I attach is better
still.
1) It adds a reminder to fix this properly in Tk 9
2) It removes the assumption that MappingNotify and VirtualEvent are
necessarily contiguous
3) It adds a Tcl_Panic if one of these things hits us for real (so we can
figure out what to do when that happens)
File Added: genericevent.patch

Logged In: NO

@dkf --

> I'm not convinced that that's the right fix *unless* ABI compat is
> prioritized over the unholy mess that will result the first time a
> GenericEvent is dropped on our laps.

Under what circumstances would a GenericEvent ever make its way into Tk's
event loop? I can't find any way that this would ever happen in any
existing release of Tk.

I'm not convinced that that's the right fix *unless* ABI compat is
prioritized over the unholy mess that will result the first time a
GenericEvent is dropped on our laps.

Bleah. "Why, X.Org, why?"

File Added: tk-lastevent.patch

I've been googling around and it seems that the X.Org plan is to move all
extensions over to using generic events (I don't remember which blog I read
this on). Leaving aside whether this is a good plan of theirs, it does mean
that we can't count on not getting GEs dropped on us (well, not unless we
compile and link against old headers/libraries, which is what the strict
ABI compat folks need to do anyway). Analyzing GAH's patch from the gentoo
bug report, the problem (for now) is that we encode the fact that LASTEvent
is 35 (it isn't any more) in the flagArray in tkBind.c. GAH's fix adds a
another dummy entry, but I think it is neater to split the table into two;
one for the X11 events and one for Tk's virtual events. (We'll also need to
fix all the places that read from that array; thankfully it's file-local.)
The fixes need backporting, probably back as far as 8.4 (do we support 8.3
any more at all?) but that should be easy as this part has been static for
over a decade (since Win and Mac support was added I guess).

It is worth considering whether we should move Tk's synthetic events
elsewhere entirely? ABI compat's bust anyway. If we change it so that Tk's
synthetic events have a non-zero high byte, we'll be completely out of the
way of all the events that X11 defines (which I think are byte-ranged I
believe); we've got space, as the structure uses an int to hold the type
field.

@dkf --

| Further examination indicates that it is not possible to prevent the
| delivery of GenericEvents to Tk without abandoning the use of all
| extensions (XIM being the one we need more than any other, alas)

Where do you see this happening? Tk does not, by itself, select for
GenericEvents on any window that it creates, so it should not receive any
AFAICT.

XIM does not, by itself, rely on GenericEvents either. (XInput might, but
that's a different extension - it deals with multiple keyboard and pointing
devices. Tk does not use XInput).

Another extension which mentions ActivateNotify is BLT.

At least one extension uses VirtualEvent, ActivateNotify and
DeactivateNotify. It's Tile extension.

Further examination indicates that it is not possible to prevent the
delivery of GenericEvents to Tk without abandoning the use of all
extensions (XIM being the one we need more than any other, alas). Now, if
generic events had been structured as an extension, we wouldn't have been
bitten. But they weren't so we were.

Principal concern: whether there are any extensions that use Tk's faked up
MouseWheel, Activate and Deactivate event numbers directly (instead of
using a binding table). If not, we can just fix Tk and everyone else will
come along for the ride.

Cause of the problem: parts of Tk have a hardcoded assumption that the X11
protocol constant LASTEvent is #defined to be exactly 35 (== MappingNotify
+ 1). In particular: the 'flagArray' and 'eventMasks' static array
initializers in tkBind.c resp. tkEvent.c; possibly others as well.

This has been a valid assumption (from 1991 up until very recently), but
X.org xproto-7.0.13 added a new "GenericEvent" event type and incremented
LASTEvent.

This problem affects all versions of Tk from 4.0 through 8.6a1, as well as
any extensions that reference the Tk extension event types VirtualEvent,
ActivateNotify, DeactivateNotify, and MouseWheelEvent.

Proposed short-term fix: replace all uses of the symbolic constant
LASTEvent with MappingNotify+1. This should restore source-level
compatibility with newer Xlib releases and preserve ABI compatibility for
Tk extensions. Conflicts between Tk "VirtualEvent" events and X11
"GenericEvent" events should not be a problem -- Tk does not select for
GenericEvents, so it should never receive any from the X server (@@@ need
to confirm this).

Long-term fix needs further discussion.

The following bug in gentoo shows that the problem is in an incompatible
changes in xproto-7.0.13: http://bugs.gentoo.org/show_bug.cgi?id=225999 (or
it's a Tk fault where it cannot survive a new event in X protocol?)

Error is reported at runtime, not a
flaw in building.