Newsgroups: comp.windows.x
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: pete@iris49.biosym.COM (Pete Ware)
Subject: Xt Intrinsics, extensions, and event handlers
Message-ID: <9105302204.AA08805@iris49.biosym.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
References: <9105301452.AA24478@lyre.MIT.EDU>
Date: 30 May 91 22:04:57 GMT
Lines: 60

I understand the need for having a clean solution that supports
translations, selecting for events and dispatching events all working
on multiple displays (remember, event numbers can change from display
to display) is complicated, it's just that the current mechanism
provides absolutely no way to deal with extension events in a normal
dispatch loop!

>>   The problem is that Xt doesn't seem capable of dispatching any nonmaskable
>>   events to the event handler other than GraphicsExpose, NoExpose,
>>   MappingNotify, SelectionClear, SelectionRequest, SelectionNotify, and
>>   ClientMessage

>Also correct.  These are very explicitly specified to be the [only]
>events referred to by the 'nonmaskable' argument to XtAddEventHandler.
>Actually, MappingNotify is a mistake; see below.

>>    Shouldn't event types outside the range of the X standard protocol be
>>    considered nonmaskable events by Xt?
>>
>Perhaps but that would now be a significant backwards-incompatible
>specification change and is therefore not acceptable.  An additional
>difficulty is that it is not correct to assume (or require) that
>all extension events have usable 'window' fields.  MappingNotify
>is the only core event that doesn't contain a window and it requires
>quite a bit of internal manipulation in Xt to dispatch it reasonably.
>

Could you at least make it possible to handle non-recognized events
instead of just discarding them?  When I first started looking into
this I initially (and incorrectly) assumed that adding a raw event
handler and setting non-maskable to True, I'd get all the extension
events passed to this handler.  It made sense, since one cannont
select for the extension event and any handlers for non-maskable events
certainly have to check the event type in any case, but it didn't
work.

>An aside; rather than "fixing" the implementation to dispatch
>MappingNotify to all event handlers registered with nonmaskable==True,
>we propose to change the spec to remove this event from the 'nonmaskable'
>list.  As of R4, it is possible to express interest in MappingNotify
>through the translation table mechanism and this appears adequate.

It seems that removing MappingNotify from the list of nonmaskable
events is a far more serious a change than dispatching additional
events to handlers for nonmaskable events.  After all, handlers for
nonmaskable events already should handle GraphicsExpose, NoExpose,
SelectionClear, SelectionRequest, SelectionNotify, ClientMessage and
MappingNotify.

>I hope I've convinced you that this is far from sufficient.

I'm begging for minimal support so I don't have to force every
application that wants to use an extension to write it's own private
dispatch loop!  I can live without the ultimate solution, but life is
hard with the current situation.

--pete
Pete Ware / Biosym / San Diego CA / (619) 546-5532
     email: pete@biosym.com