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

[raster redhat com]

On 19 May, Bowie Poag shouted:

[.... snip .... agreed. good idea ]

->   There are two ways to go about changing the appearance of a Lamp, or
->   of a Beacon on the desktop. With InSight, the plan was to simply change
->   icon on the fly, by loading in the appropriately-colored icon in its
->   place, if need be. The second way, which takes considerably more CPU
->   time to pull off, involves hue-shifting the image data within the icon
->   +/- 180 degrees to achieve the desired color.

if the icons are small (8x8, 16x16 or around that range) the amount of
cpu needed to process that image is trivially small. (8x8 would mean 64
operations of hue-shift for the icon. 16x16 would mean 256 ops (the ops
are fairly simple ones too and can be throwin into the rendering stream
of imlib when I get a chance)

->   The first method requires a small cache of colored icons to be present,
->   and ready to be loaded in. Ususally, about eight different colored
->   lamp icons (and eight beacon icons, respectively) are enough to handle
->   most situations. Appendix B (mentioned above) contains a small archive
->   of example lamps and beacons in different colors for you to look at,
->   and experiment with. The eight colors are Clear, Blue, Aqua, Green,
->   Yellow, Amber, Red, and Purple.

Even though the colro shifting is trivial I prefer the multiple icons
method.. it much more nicely quantizes the problem of having to pass
these states ot somehtng else to draw for the app - and it doesnt limit
the system to only use color. Shape can be used too. another very
important human facet you have missed. we not only react and can judge
somehting by its color, but also by shape. This si well demonstrated by
todays use of icons an signs that depict images not just by color but
by their content. Allowing a user to sleetc what icon he wants for
certain states is probably the best solution.

->   Thats right, the raw image data has already been provided for you. These
->   icons are in all respects ready-to-use.
->  
->  
->  C. Implementation
->  
->   Here's how to go about constructing a control panel to handle behavior
->   sets for color-reactive desktop elements. 
->   
->   The user should be presented with a list of potential "states", (like
->   Busy, Idle, Sleeping, Error, etc) and then be given the ability to map
->   colors of their choice for each state.

Good Idea. now before anything can be done we need to define exactly
what these states are, how many there are, and what each means and how
they shoudl be used by an app correctly and by the display mechanism.

->   The "Color Transition Table" allows the user to specify the physical
->   behavior of the Lamp, or Beacon. A whole big row of "C" means simply
->   "for this behavior, the color always remains clear" ..Just the same
->   as a repeating sequence of "BRBRBRBRBRBR" would make the lamp
->   rapidly flash between Blue and Red, over and over again. To slow down
->   the rate of blinking, imagine a sequence like "BBBBRRRRBBBBRRRR".
->  
->   Get it? This is a little difficult to understand for some people, so,
->   take your time.

easay. fame sequences. shoudl use an array of ints int he end tho maybe
as a hint on a window that are indicies to "defined" icons for states.

->   The Color Transition Table allows the user to specify the sequence of
->   colors it shows to indicate each specific "state" .. Like if you wanted
->   to get the user's attention, you would probably want to make the Lamp
->   or the Beacon flash rapidly. This can be done by alternating the sequence
->   of colors, like drum beats in a song. To use an analogy, the lights on a
->   police car can be thought of as color-reactive elements. When the police
->   car is in a state called "Pursuit", it's behavior is Red, Blue, Red,
->   Blue, Red, Blue.
->  
->   Here's how to read the table:
->  
->   RRRR = Red Red Red Red, and RBRBRB = Red Blue Red Blue Red Blue. To make
->   a Lamp or a Beacon flash like its on fire, a sequence like ROYOROYOR
->   will make it strobe from Red to Orange to Yellow to Orange to Red,
->   repeatedly. Now do you get it? :) 
->  
->   The Color Transition Table allows for a tremendous amount of flexibility
->   when dictating the precise behavior of color-reactive desktop elements.
->   By simply changing the entries in the table, you can do everything from
->   solid colors, to wild rainbow effects, just by playing with the order of
->   colors for each state.
->   
->   Have a look:
->  
->  +--
->  | ----------------------------------------------------
->  | Example Behavior Set #1:
->  |
->  | Key:  A = Aqua    C = Clear   O = Orange  B = Blue
->  |       Y = Yellow  V = Violet  R = Red     G = Green
->  |      
->  |
->  | State               Color Transition Table
->  | ------------------  --------------------------------
->  | Idle                CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC \
->  | Sleeping            BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB  \
->  | Low CPU Usage       VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV   > Solid Colors.
->  | Moderate CPU Usage  RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR  /
->  | Heavy CPU Usage     OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO /
->  | Severe CPU Usage    YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
->  | Attention           GGGGGGGGCCCCCCCCGGGGGGGGCCCCCCCC \  See how you can
->  | Error               RRCCRRCCRRCCRRCCRRCCRRCCRRCCRRCC  > set the behavior
->  | Busy                ACCCACCCACCCACCCACCCACCCACCCACCC /  to blink stuff?
->  | ------------------  --------------------------------
->  +-- 
->  
->   This is what the behavior set would look like if you wanted to:
->  
->   Clear color for Idle
->   Blue for Sleeping
->   Violet for Low CPU Usage
->   Red for Moderate CPU Usage
->   Orange for Heavy CPU Usage
->   Yellow for Severe CPU Usage
->   Slow Blinking Green/Clear for Attention
->   Fast Blinking Red/Clear for Error
->   Normal Blinking Aqua/Clear for Busy

kewl. You took the visual into account.. I suggest sound be run in
parallel:) (ie defin a sound to make for a state - of course most
states will have none - but bad error states for example may have a
little "bzzt bzzt".

->  [ IV. Usage Examples ]
->  
->  Color, in this case, can be shown as a function of CPU usage:
->  
->   Dead                     Clear
->   Light                    Purple
->   Moderate                 Blue
->   Heavy                    Green
->   Severe                   Yellow
->   Extremely CPU-Intensive  Red
->  
->  Or, as in this case, as a function of process state:
->  
->   Zombie                   Clear
->   Sleeping                 Purple
->   Idle                     Blue
->   Running                  Green
->   Waiting                  Yellow
->   Segfault/Dead Stop       Red
->  
->  Or, simply as a user cue, like in a 3D Rendering package:
->  
->   Waiting for User Input!  Blue
->   Busy...                  Yellow
->   Rendering..              Green
->   Error!                   Red
->   Finished!                Clear
->  
->  
->  As you can see, instead of using simple solid colors, lamps and beacons
->  can be made to -flash- colors, like flashing red to indicate a
->  catastrophic failure, and alert, or even an incoming message.
->  
->  A pager program, or email checker could be collapsed into a beacon that
->  would turn green whenever you had a new message waiting for you to read.
->  A packet sniffer could be made to flash red whenever suspect ICMP packets
->  are recieved. An FTP client could use its Lamp to indicate the various
->  stages of connection to a host, or the progress of a file transfer. These
->  are just a few ideas I came up with off the top of my head --  The
->  possibilities for implementation are endless. 
->  
->  [ V. Questions & Answers ]
->  
->  Q: "How in the world are you going to tie all of this to the OS? ..And
->      do it without dragging the entire system to a crawl?"
->  A: "The code responsible for color-reactiveness can (and should) be
->      tied directly to /proc, or something which watches /proc for you.
->      Updating the color of a Lamp or Beacon should only occur maybe 4
->      to 6 times per second, optimally. Yes, I did my homework, and yes,
->      I actually sat down and did the math. Updating the color of the
->      Lamp or of the Beacon that frequently shouldn't take much effort.
->      Setting up a watchdog process which monitors /proc (as opposed to
->      hitting up /proc directly) makes it possible to do stuff like remote
->      monitoring of other systems across networks, which was part of the
->      original plan with InSight, to begin with."

proc proc? why do we need proc? much better bone by an app aware of
this system setting properites (hints) on their toplevel windows and
changing the properteis contents whenever needed (ies the app can say
"flash red" "flash blue" "flash red" etc. a WM will easilly pick this
up as a propertychangeevent from X and can re-read the property get the
new value and do whatever it sees fit with this information - anywhere
from displaying it in the titlebar or under the windows icon or in a
sate monitor box or completely ignore it as it sees fit.

->  Q: "Nice idea, but just -how much- CPU time is this going to take?"
->  A: "Next to nothing, if done right. No more CPU time than it takes to
->      animate a GIF file on a web page, if done right. However, I would also
->      imagine that the CPU toll would be proportionally heavier when several
->      windows are open, or many, many Beacons are present on the desktop.
->      Certainly, the CPU penalty would never be so severe as to cause an
->      unneeded hinderance to the machine."

it woudl take insignificat amounst of cpu 1. if indivitual icons are
used for each state rather than hue transitiosn this is a hware
accelerated function and most likely (on a system that isnt being
stretch to the limit as far as video ram goes), the pixmap for such
icosnb will have been cached byt he Xserver alreday in he spare area o
the frambuffer - so displaying the new pixmap is completely done
onboard the gfx card - he cpu issuing a request to the "blitter"
onboard the card to copy onto screen. in worse situations i may mean
copying a few bytes across the bus to the video-card. trivial on todays
cpu's - and even yesterdays.

->  Q: "I'm a little fuzzy on all of this...Errrr... So, lemmie get this
->      straight.. Color-reactiveness is when the OS is monitors the status
->      of each process present on the desktop, and changes the little light
->      up in the corner of the window to reflect whats going on, according to
->      a set of user-specified colors configured ahead of time...?"
->  A: "Bingo."

it should have squat to do with the os but instead be part of an api
(ie can we say extened WM hints?) tghat people conform to and try and
make use of.

->  Q: "Why didn't you just use traffic lights as an analogy?"
->  A: "Because traffic lights aren't really color-reactive. Traffic lights
->      use a separate lamp for each state (red for stop, yellow for warning,
->      green for go, etc) ....Lamps and Beacons only employ ONE light,
->      respectively, which has the capability of showing SEVERAL colors.
->      Traffic lights are a poor analogy."

its arbitary - allow users to pick their icons for states and you can
have both. :)

->  Q: "I'm not quite sold on the idea..Color-Reactiveness seems like more of
->      a gimmick than something really useful to me. Convince me that its
->      not just eye candy."
->  A: "Allright. How many times have you had applications inexplicably lock
->      up on you without any real indication of what went wrong, without
->      digging up the process list, or looking at 'top' to find out what
->      happened? How many times have you had to babysit an entire screen full
->      of progress windows, all of which having their own progress
->      indicators? How often have you been bugged by annoying and obtrusive
->      pop-up windows telling you when something has been completed? How
->      often have you wanted to know at a glance whether or not something
->      you're running is performing up to snuff? Color-reactive desktop
->      elements can alleviate ALL of these problems, quickly, and elegantly.
->      As long as we have the opportunity to do so, we should include it
->      -now- before anything has really been set in stone. 

yes it's genuinely useful - but taken to the point of being much too
specific here - he generalization of it leads to the app advertising
its state via lets say properties to someone else who will, if
intrested pcik up these hints and draw something.. these hints on state
shoudl be definied by a standard ie standard states are:

0 Inactive
1 Calculating
2 Awaiting Data
3 Error 1  (2 for blinking)
4 Error 2  (2 for blinking)
5 Require user information
6 Struggling (for cpu , ram or bandiwidth - take your pick)
7 Reading Files
8 Overloaded
9 --- Unused
10 0% done
11 10% done
12 20% done
13 30% done
etc.

(i'm sure allowing 2 states for each liek Error 1 and Error 2 woudl be
god to allow "blinking")

->  Q: "How are Beacons different from Lamps, again?"
->  A: "Beacons are smaller versions of Lamps. Lamps are little gadgets which
->      sit directly on the window frame of an application. When you iconify
->      the application, it turns into a Beacon.. A little icon on your
->      desktop with a tiny little Lamp up in the corner, so you can still
->      watch it and see whats happening inside the application without it
->      being open."

We are definitely talking window manager land here... :)

->  Q: "No, I mean, why should GNOME incorporate this idea into the design?"
->  A: "Alot of reasons. For one, it would set GNOME apart from its
->      competitors, as being an innovative (and more importantly, a NEW)
->      improvement to traditional GUIs. Linux needs to set itself apart from
->      all the bloat, bullshit, and hype intrinsic to other platforms by 
->      addressing the problems contemporary users face when dealing with
->      GUI's in general. Color-reactiveness is a useful idea, fairly easy to
->      implement, and would only take a minimal amount of system resources to
->      pull off. Above all that, its just plain cool to have. :)"

Agreed - the more feedback to the user the better.

->  Q: "What if you *DO* end up having a ton of windows open on one screen,
->      and your system begins to slow down as a result of having to
->      continually update all these little lights?"
->  A: "A smart programmer will write the code responsible for handling
->      color-reactiveness such that this never happens. If the total number
->      of Lamps and Beacons on a screen exceeds a known threshold, the 
->      frequency of updating them should be reduced to compensate for the
->      load they incur on a system. Simple load balancing."

I can't see a system slowing down form this.. okay maybe an 8086... but
then again.. that aint gonna be runing linux and X... :) if a machine
can manage to get x up this shoudlnt be too bad.

[... agree snip ...]

->  Questions or comments?
->  
->  Bowie J. Poag - bjp@primenet.com     University of Arizona, Comp. Sci.
->  ex-InSight Core Development          Tucson, Arizona.
->  Tel: (520)/327-5259

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