Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!ptimtc!nntp-server.caltech.edu!toddpw From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel) Newsgroups: comp.sys.apple2 Subject: Re: GS PALETTE Message-ID: <1991Jun11.225928.5968@nntp-server.caltech.edu> Date: 11 Jun 91 22:59:28 GMT References: <4044.apple.a2.net@pro-nbs> <1991Jun9.030323.1164@nntp-server.caltech.edu> <53861@apple.Apple.COM> Organization: California Institute of Technology, Pasadena Lines: 31 dlyons@Apple.COM (David A Lyons) writes: >It seems a little strange to consider *changing* the color table behind an >application's back as fixing a problem. But if that's what you want, the First of all, the color table is not changed behind the application's back. A patch to InitColorTable would simply change what the default 320 mode color table is. Detecting the active status of the window manager would make it even more transparent since we only care about fixing things when there will be a desktop picture drawn. I and the person who started this thread would consider it a FIX because IMHO the 320 and 640 mode palettes should have been consistent to begin with. The deskpicture method you graciously supplied to us last year (which subsequently appeared in toolbox ref 3) does not account for the fact that the two standard color tables are inconsistent -- my current picture is colored properly for 640 mode but looks like a photographic negative when I run a 320 mode application. Since the default color tables are fixed in stone, there are two ways to get reasonable looking pictures in both graphics modes: patch out InitColorTable when the Window Manger is active remap the deskpicture image whenever the QD master SCB changes modes Since most 320 mode applications install custom color tables anyway, I don't see the InitColorTable method as a real problem. I see my deskpicture in screwball colors a lot more often than I see application colors that depend on the standard 320 mode color table. Todd Whitesel toddpw @ tybalt.caltech.edu