Re: A Proposal For The Addition Of Color-Reactiveness To The GNOME Desktop

[Bowie Poag <bjp primenet com>]

On 20 May 1998, Rob Browning wrote:

> 
> I'm not sure what I think of all this, but I do have a couple of
> comments:
> 
>   1) I think that instead of beacons for the icons, that if you wanted
>      to pursue this, applications should just be allowed to treat
>      their icons as small windows, and should have a good drawing
>      toolkit for rendering into them.  For example, why shouldn't an
>      iconized FTP transfer, in addition to having a light indicating
>      the state of the connection, have a small pie chart, numeric
>      display, or other progress meter showing the percent complete?
>      Same thing goes for other apps.  An iconized rendering window
>      could show a minaturized version of it's progress so that it
>      would be easy to see how far it's gotten.


Variations on a theme. Its an interesting twist on the idea, but, the need
to maintain visual consistancy thruought the interface should be topmost
priority. Having a whole pot full of different indicator styles would
probably end up doing more harm than good. Lamps and Beacons provide
enough flexibility (and visual consistancy) to be used in nearly 100% of
all situations which require monitoring by the user. Simply rendering a
miniature of the window would be a mistake, imho.

I see what you're saying, though.. To have additional indicators, like pie
charts for FTP transfers, coexisting with stationary lamps within a
window. I like the idea, but I fear it may be redundant.


> 
>   2) Using the type of strings you describe to represent the color
>      transitions seems like a limiting idea.  Off the top of my head,
>      you'd be better off using something like this
>  
>        "B=DarkBlue R=Red G=#007700 B 1.0 R 0.2 G 0.5"
> 
>      where you define the colors, then use them in an alternating list
>      which contains alternating pairs of a color abbreviation and a
>      time in seconds.  This makes it much more flexible (and easier to
>      read) when specifying long periods.  It also links the delays to
>      wall-clock time in a very obvious manner, something you probably
>      should do.

There are 32 positions in the Color Transition Table, kinda like drum
beats in a song. When a state is triggered, the table dictates the order
of colors which are displayed. This allows you to have color-reactive
elements stay lit solid, blink extremely fast, blink frequently, just
blink, blink slowly, blink occasionally, and blink rarely. Its not just
for blinking, either. If you wanted to make a Lamp or Beacon start
changing color like a rainbow, its as simple as ROYGBIVROYGBIVROYGBIV.
At the risk of sounding like Bill Gates, "32 positions ought to be enough
for anybody." :)

Keep in mind, the decision to use 32 positions in the Color Transition
Table example (as opposed to 24, 48, or some arbitary number) was thought
about ahead of time. It turns out that 32 positions is the best comprimise
between flexibility, and excessiveness. 

I see your point, tho -- I just dont see the need to give the user that
degree of freedom when choosing Lamp and Beacon color. Sure, it would be
nice.:) But with freedom comes responsibility. Lets suppose 3 years from
now, color-reactiveness has caught on, and everyone uses it.. And just by
virtue of public opinion, Blue always means sleeping, and Aqua always
means running. What happens if someone comes along and tries to make a
Lamp which is halfway between Blue, and Aqua? Which is it doing, sleeping
or running? Denying the user the ability to arbitrarrily choose the color
of color-reactive elements from a pallete of 16.7 million would open a
Pandora's Box of sorts. Its one of the rare occasions you'll see where
giving the user ultimate freedom is a bad idea.

Its like dealing with crayons. You're never going to need more than that
big box of 64, most kids are happy with 48, and nearly everybody can get
by with just a small pack of 16 :) The same applies to color-reactiveness,
in my opinion. 8 different static color states are enough to convey the
total number of possible states expressable by any paticular program.


Bowie J. Poag