Daniel Macks wrote:
[]
> Does incorporating this patch mean that a libtk build against an
> "older" libX11 will not work properly if libX11 is upgraded to one
> that has these renumbered events? That is, are the constants
> *different* on an older x11 with vs without the patch (either the one
> here or the more complicated one in the sf item)?
No, the whole purpose of the patch is to give the *same* numbers to the
events on new X11 as on old X11. Writing LASTEvent, LASTEvent + 1,
LASTEvent + 2 is just a glorified way of writing 35, 36, 37 (which would
probably be more honest and - as this story is proving - not less flexible).
The only problem that can arise in the future (but with the ancient
version of tcltk we have in Fink we shouldn't worry too much about the
future) is when X.org starts using the new extra event "GenericEvent"
that they introduced and which made it necessary to raise the LASTEvent
count.
But then I don't know anything about the relation between X events and
Tk events. The current problem is not about this relation. It is a
purely internal problem of bad programming inside Tk. They used the
macro LASTEvent, which is controlled by X11 and not by Tk, to enumerate
elements of Tk's own static arrays, elements that are precisely *not*
corresponding to any X events. The first 34 Tk events, if they are
defined at all, correspond to X events, but numbers 35 ("VirtualEvent")
and 36 to 38 ("Activate", "Deactivate", "MouseWheel") are Tk additions.
This way of doing things was bound to lead to breakage as soon as
anything on that front was moving in X11.
The static arrays "flagArray" and "eventMasks" of size TK_LASTEVENT (=39
as hardcoded, but written as LASTEvent+4) that break when LASTEvent
changes are purely internal to Tk; they are defined in *.c files and not
accessible via headers. The part of the event list that extends the X
event list is defined in a header, tk.h, also to be found, for example,
in /System/Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h.
This file tk.h also contains the definition of the macro TK_LASTEVENT,
and this is the reason why patching this header file is the simplest way
to avoid breakage.
As a second thought, a cleaner patch would after all be to not fiddle
with LASTEvent, but simply put the indices explicitly, like this:
*---------------------------------------------------------------------------
*
* Extensions to the X event set
*
*---------------------------------------------------------------------------
*/
#define VirtualEvent 35
#define ActivateNotify 36
#define DeactivateNotify 37
#define MouseWheelEvent 38
#define TK_LASTEVENT 39
#define MouseWheelMask (1L << 28)
#define ActivateMask (1L << 29)
#define VirtualEventMask (1L << 30)
#define TK_LASTEVENT 39
As seen by the preprocessor, this is completely identical to what is
there currently (with old <X11/X.h>). Nobody knows why they #define
TK_LASTEVENT twice, but it is there like this in all versions of tk.h,
up to the latest one from Tk CVS.
--
Martin
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
