🚀 go-pugleaf

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