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

[raster redhat com]

On 20 May, Bowie Poag shouted:
->  
->  
->  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.

see my other mail.. add extra states for an app:
0% done
10% done
20% done....
etc.
its coarse, but sufficient enough for a small icon to roughtly shwo
where things are - for more detail check the app itself.. (ie
de-iconify etc.) :)

->  >   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

gotta luv ya.. using powers of 2 :) 

->  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." :)

i'd have to agree... :) but thenagain just havign a lot of states will
do that for us.. :)

->  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. 

there is no such thing as excessive! :):):) you can never have too
much!:)

->  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.

don't worry.. :) I'll think abotu it today and add WMhints into E
tonight for it.. and trust me.. there'll prolyl be many mroe than 8
"states" by the time I'm done with it.. :)

->  Bowie J. Poag
->  
->  
->  

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/