dubois@uwmacc.UUCP (01/31/87)
After posting the recent fixes to the TransSkel stuff, I received
some comments that I think warrant more general discussion. Briefly,
my correspondent believes that TransSkel's behavior with respect to
setting ports is wrong, but I will let him speak for himself:
---
* From the initial release of TransSkel I've felt that it handles one
* thing incorrectly: the setting of the current port. There are two
* places only where TransSkel should change the current port: in response
* to an activate event and in response to an update event. In the latter
* case the port should be changed temporarily to the window to be
* updated, the update procedure for the window should be called, and then
* the port should be restored. ** From the user's viewpoint the port
* doesn't really change.** In the case of activate events the port is
* permanently changed to the window being activated, presumably in
* response to some user action. ** From the user's viewpoint the port
* only changes in response to some action of his.** This is in the
* spirit of the user interface guidelines, and you won't find anything in
* Inside Macintosh to indicate that things should be done otherwise.
* In no other situation does TransSkel have any business messing with the
* port, but in fact it changes the port all over the place. This strikes
* me as just asking for bugs to crop up.
* In general the application program built on top of TransSkel should not
* change the current port, and when it does it should be a temporary
* change in the space of a single procedure, much like the change during
* update. ** Application programmers need to understand this, not have it
* magically enforced by excessive use of SetPort within TransSkel.**
* The proper way to remove a window is to hide it, to handle the deactivate/
* activate events locally, and to then dispose of the hidden window.
* This would eliminate the problem you had with ZoomWindow without yet
* another unnecessary SetPort.
---
My response to this was partial agreement. I did ask what the
port should be set to when a window gets clobbered. TransSkel sets
it to the window manager port to avoid dangling ports. Perhaps
this is unnecessary; the response to my question was:
* What do you set the port to when a window is disposed? Is it
* necessary to set it to anything? Activate events should cause the port
* to be set. When the last window goes away there won't be an activate
* event, but neither will there be any further update events; so the
* user's program shouldn't be doing any more drawing that requires the port
* to be set.
* One addition to my suggestion in the previous mail: the routine that
* handles the deactivate/activate events locally when you hide a window
* in preparation for disposing of it might ought to handle outstanding
* update events also.
* By the way, this idea is not original with me. I've encountered it in
* other people's code ... Stephen Chernicoff explains
* this technique for closing windows on pages 86-87 of Macintosh
* Revealed, Volume Two.
---
Anyone have any comment? I think the remarks above has merit, but
I'd like to hear what other people thing before I start hacking away.
---
Paul DuBois UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois |
ARPA: dubois@easter --+--
dubois@rhesus |
|
"My help does not come from the hills"
Psalm 121:1