oster@dewey.soe.berkeley.edu (David Phillip Oster) (04/08/89)
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." - Gaseewdh@well.UUCP (Bill Hofmann) (04/11/89)
In article <28735@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >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. In fact, I think apple mentions that programs should do this, but I agree that the standard WDEF should do it. Besides providing the concept of multiple monitors being views onto adjacent parts of a big desktop, Apple has done NOTHING to support development. I have a whole set of routines that have to traverse the device list to figure out what screen to center windows on, or to determine how to clamp window positions, or to determine which device has the largest area of a window, etc. etc. >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? Two that I've reported repeatedly that I haven't tested recently, but have NEVER been mentioned in release notes as either fixed bugs or known bugs are: 1. move a color window so it spans a 1 bit and an 8 bit screen. If the window contents have more than black and white, when you ScrollRect such that an area from the shallow screen ends up on the deep screen, ScrollRect just CopyBits it, leaving a black and white band which isn't accumulated into the update rgn. So if you want to do it right, you have to do a ScrollRect for each device the window spans (another reason to traverse the device list), and accumulate the correct updateRgn. Several of Apple's QD engineers have acknowledge this one. 2. If the main screen is 1 bit and another screen is 8 bit, the Color Picker will NEVER show the right number of colors, no matter where you place it on the 8 bit screen. To Apple's credit, once MacDTS started fielding bug reports, I started seeing my bug reports answered, and some of them solved. -Bill Hofmann
svc@well.UUCP (Leonard Rosenthol) (04/13/89)
Another interesting bug in CQD related to color Icons (cicn's). The PlotCIcon routine has this REALLY neat bug in it, rather than checking the current GDevice to see how to plot the cicn, it checks the main monitor instead - this is great for multiple monitor (B&W main) setups!! I had to write my own PlotCIcon routine for MicroPhone II v3.0 so that we could avoid the problem. I believe that Apple knows about this one, but it is worth mentioning. -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025