NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/sys/mac/system/13955

Text File | 1992-11-10 | 3.7 KB | 78 lines

Newsgroups: comp.sys.mac.system
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!jvnc.net!princeton!phoenix.Princeton.EDU!jdunning
From: [e-mail] (John Alan Dunning)
Subject: Re: Is there a way to change Icon/Window outline color?
Message-ID: <[e-mail]>
Originator: news@nimaster
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: phoenix.princeton.edu
Organization: Princeton University
References: <[e-mail]>
Date: Wed, 11 Nov 1992 08:52:03 GMT
Lines: 64

In article <[e-mail]> [e-mail] (Joe Riddle) writes:
>     I was just asked by a colleague of mine if there was a way
>to change the color of the outline that appears whenever you
>move a window or an icon around on the desktop.  Apparently he has
>spent hours coming up with the perfect desktop color but is now
>terribly upset that the outlines can't be seen because they blend
>into the color of the background.
>
>     Is there a shareware/freeware solution to this problem or
>a resedit hack that someone could point me to?  Thanks in advance
>for any assistance.
>
>                      Joe
>
>-=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=-
>                   Joe Riddle
>                Systems Supervisor
>               Stanford University
>              Payroll & Records Dept.
>             [e-mail]
>-=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=-

Not that I know of.  If you look at the color of the outline, you'll
notice that it's not a single color, but many colors.  The color of
each pixel in the outline depends on the color of the background pixel
which it is currently sitting on.  So the colors of the outline pixels
shift as you move it over different-colored background pixels.

I'm not exactly sure how the colors are determined.  I know that in a
black and white display, the color values are simply inverted, so that
black pixels become white and vice versa.  Nice and simple.  In
theory, you can do the same thing with color pixels; simply invert the
bit patterns representing the colors.  So in 24-bit RGB format, pure
red would be represented as 1111 1111 | 0000 0000 |  0000 0000.
Inverting that gives 0000 0000 | 1111 1111 | 1111 1111, which
corresponds to cyan.  The problem is, in 256-color mode, the 8-bit
color values stored in each pixel correspond to a position in a color
"map", which in turn corresponds to an actual 24-bit color.  So
inverting 8-bit color map values just maps a different color into that
pixel, which doesn't necessarily produce the actual "inverse" color.

This may actually be what's happening.  It looks like black is at
position 0 and white at the inverse position 255 in the standard system
pallette (judging from the pallette displayed at the bottom of the Monitors
control panel), and black and white are always mapped into one another
when moving an outline.  It looks like the same holds true for other
colors in the pallette, though it's hard to tell.  Does anyone want to
look this up in Inside Mac?

So the possible solutions to your friend's problem are 1) change the
background colors (this might only require a slight shift, so that a
color will map into a different, more contrasting color), 2) change
the System pallette in ResEdit, which might adversely affect the
colors which appear in the Finder or other apps, 3) run in 24-bit
color mode, which makes the outlines much more visible, presumably
because you're getting truly "inverted" colors, 4) live with it.

There's also a shareware init called RealDrag which actually drags a
solid window, instead of just an outline of it, a la NeXT.  If you've
got a reasonably fast Mac, there's no real speed penalty.  Icons,
however, are still dragged as outlines.


John