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





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

Right. That was the whole plan with the control panel.. Just a huge long
list of possible states which can be expressed by applications running on
that paticular system, and the color transitions for each.

> ->  
> ->  There are 32 positions in the Color Transition Table, kinda like drum
> 
> gotta luv ya.. using powers of 2 :) 

Heheheh.. Its like one of those "You know you're a computer geek when.."
:) I can name all the powers of 2 up until 2^17th or so.. Heee
> 
> ->  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.. :)

Exactly. The number of colors available isn't nearly as important as the
number of WAYS you can depict the colors..strobing, flashing, blinking,
solid, you name it. There are literally tens of thousands of ways to
depict 8 colors within a 32-step pattern like what we see in the
Transition Table. It was engineered that way.

 
> ->  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! :)

Ha. Well, if you can convince me that a lamp with a color of #0000FF is
wholly different in meaning than a lamp with a color of #0000FE, and
totally obvious to everyone, i'll back you up on it. :) Hehehe.. Thats
like telling someone to turn down the light in your living room a little,
so they walk over to the lamp and turn the dimmer down like one or two
angstroms counterclockwise. "There, I turned the lights down." :)

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

Wham-o.. 8 different colors, used in different combinations to depict a
whole multitude of different operational states.



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]