[comp.windows.x] X11R3 user reports back

mark@sunquest.UUCP (Mark Langley) (11/16/88)

A coupla things, but first, kudos to the X consortium!

2.
In the documentation for XtRemoveEventHandler it says (and I quote..)
  To stop a procedure from receiving any events, which will
  remove it from the widget's event-table entirely, call 
  XtREmoveEventHandler with an event_mask of XtAllEvents
  with nonmaskable True.
    (page 76 in the King James Version)

I don't think it means this.  I looked in the source and the code
was a little odd...  Namely, it still checks for p->closure (i.e.
that client data matches what was registered) and it then
it blips out the event mask.

This seems unorthodox, since you have to *unregister* an event with
an event mask it was never registered with, but also tell it you're
unregistering it with respect to a particular client_data
registration... (Still with me?..)

Am I reading this right?

3.
I noticed that you broke some of my code by making Position into
a short from an int... That's ok, it's probably my own fault
for not using Position instead of int...  But why is it that
(x,y) coordinates in Xlib are still defined as ints!?  i.e.
why save space in Xt if you just give it up again in Xlib and
in the server?  (see XQueryPointer and XTranslateCoordinates...)

Thanks in advance.
Mark Langley

mark@sunquest.com		"Don't worry, be happy"
{uunet,arizona}!sunquest!mark

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (11/16/88)

    I noticed that you broke some of my code by making Position into
    a short from an int... That's ok, it's probably my own fault
    for not using Position instead of int...

I'm glad you see it that way :-)

    But why is it that
    (x,y) coordinates in Xlib are still defined as ints!?  i.e.
    why save space in Xt if you just give it up again in Xlib and
    in the server?

We aren't giving up space elsewhere.  Xt actually stores these
values in widget structures, and when you begin to have a few
thousand widgets, the savings of changing from int to short
become significant.  Typical server implementations have since
the beginning stored these values as shorts.  Xlib almost never
stores anything internally, but structure components that
mirror the protocol are typically defined as shorts.  Arguments
to Xlib functions are uniformly(?) declared as ints (or longs
when need be) just for consistency; when they get packed into
a protocol request, they still get truncated to 16-bits if that's
what the protocol wants.