Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Multiple CRTs and the guidelines
Message-ID: <28735@ucbvax.BERKELEY.EDU>
Date: 8 Apr 89 12:24:36 GMT
References: <11817@ut-emx.UUCP> <6917@hoptoad.uucp> <28734@ucbvax.BERKELEY.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Distribution: usa
Organization: School of Education, UC-Berkeley
Lines: 22

Suppose you have two CRTs, a big, slow, color CRT that you only use for
image processing, and a small fast B&W crt that has the menu bar on it.
You put up an image, drag it to the color CRT, and hit the Zoombox: it
jumps to the other CRT. This is wrong. The default zoombox behavior
should be to zoom the  to the full size of the CRT it is already on.  I've
written my programs to work that way, but it would be a simple change for
Apple to make, so all programs would work that way.

And while we are at it: there is a similar bug in the palette manager: it
only forces the palette to change for the top window. It should force each
CRT's palette to change for the top window on each CRT.  (Admitedly, this
is only a problem for programs like mine that use floating tool windows,
so image windows are "under" tools even though they are on completely
different CRTs.)

Apple has been great about fixing bugs in their system software in the
multiple CRT configuration over the past through releases. These are just
two minor, but annoying remaining nits. Any others?

--- David Phillip Oster            --"When we replace the mouse with a pen,
Arpa: oster@dewey.soe.berkeley.edu --3 button mouse fans will need saxophone
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --lessons." - Gasee