Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!snorkelwacker!tut.cis.ohio-state.edu!cs.utexas.edu!uwm.edu!ogicse!decwrl!asente
From: asente@decwrl.dec.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: cleaning up from exit
Message-ID: <3012@bacchus.dec.com>
Date: 13 Mar 90 22:43:08 GMT
References: <9003022256.AA07109@moniz.bcm.tmc.edu> <9003052005.AA24152@expo.lcs.mit.edu> <132650@sun.Eng.Sun.COM> <2999@bacchus.dec.com> <774@auto-trol.UUCP>
Organization: DEC Western Software Lab
Lines: 29

In article <774@auto-trol.UUCP> marbru@auto-trol.COM (Martin Brunecky) writes:
>In article <2999@bacchus.dec.com> asente@decwrl.dec.com (Paul Asente) writes:
>> ...(text deleted) .....  There are
>>plenty of cases in widget sets where a widget adds an event handler to its
>>parent, or to its children, or to some seemingly unrelated widget.
>>
>     I am not quite sure, but is THIS a good practice ? XUI and Motif
>     are full of instances where one widget munges another one, assuming 
>     intimate knowledge of it's internals, rather than documented
>     widget methods. This, however, makes any extension to such widget
>     set extremely difficult. 

Two good examples:

- A menu widget needs to deal with the implicit server grab on button
press and wants to pop down wherever the button release occurs.  It does
this by installing an event handler on its shell.

- A gadget wants to handle events, but it has no window.  It installs
event handlers on its parent to deal with the events.

In neither case does the widget make any assumptions about the internals
of other widgets; they just use the Intrinsics event handler semantics.  I
agree that having a widget implementation grub around in the internals of
another widget is lewd, crude, rude, and socially unacceptable, but this
is another thing entirely.

	-paul asente
	    asente@decwrl.dec.com	decwrl!asente