Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!uwvax!uwmacc!dubois From: dubois@uwmacc.UUCP Newsgroups: comp.sys.mac Subject: TransSkel - Request for comment Message-ID: <1001@uwmacc.UUCP> Date: Fri, 30-Jan-87 17:05:40 EST Article-I.D.: uwmacc.1001 Posted: Fri Jan 30 17:05:40 1987 Date-Received: Sat, 31-Jan-87 08:11:04 EST Organization: Flat Egg Software, Ltd. Lines: 72 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