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

[Bowie Poag <bjp primenet com>]

(snip-snip-snip -- Stuff about icon switching vs. hue shifting deleted)

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

Agreed. I'm also sure theres a cut-off where one becomes more efficient
than the other, in the long run. That might be worth investigating if
youre serious about implementing this idea, or at least building in the
necessary functionality into Imlib to make it happen.


.. (snip-snip)

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

Actually, we didn't neglect to examine that. We did -- But we ruled in the
end that visual consistancy of the elements themselves were more
important. At least to us, it was. Lamps and beacons can be drawn in
different styles, of course, but only the color of the lamp (or of the
beacon) was going to be the independant variable.

The number of possible behaviors which can be expressed via the Color
Transition Table should be more than enough to make up for whatever gains
could be made by allowing lamps and beacons to change shape, as well as
color. I do see your point, though.



(snip snip..)

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

My original idea was to have several often-used states, like sleeping,
running, idle, etc.. and for the behaviors of those states to be
consistant thruought the entire system. It would be pointless to have two
different programs both expressing "idle" with different colors. It makes
the whole point of color-reactiveness moot. I cant express enough, how
important visual consistancy from application to application is when it
comes to the implementation of this idea.

Of course, you're going to have programs which would like to express
different operational states like "Checking your mail..." or "New mail has
arrived!" , or "Compiling..." , or more esoteric/abstract concepts. These
states need only be to appended to the list of pre-existing states in the
Behavior Set.

Also, it may not be a bad idea for each program to have its OWN behavior
set, which dictates its behavior singularly, apart from other apps. One
email checker flashes blue when new mail has arrived. Another email
checker lights up solid green, when new mail arrives.

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

Bingo. Lamp lights up red, user points to the lamp, Hint says "Stopped."
Glad to see people are getting the picture, here. :)


(big-time snip-snip-snip)

> ->  +--
> ->  | ----------------------------------------------------
> ->  | 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?
> ->  | ------------------  --------------------------------
> ->  +-- 
> 
> 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".


Not a bad idea.. But it could get kinda noisy if you have programs which
tend to change states frequently.

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

Righto. Like I said, the whole concept of color-reactiveness would be
fairly simple to implement.. its benefits justify its inclusion, with
ease. 

Part of the fun of color-reactive desktop elements is that the user can
elect to make any (or all) lamps/beacons express whatever he or she is
most interested in.. CPU expenditure, process status from the OS's point
of view, or internal application status. Its all just a matter of changing
behavior sets.

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

Hehehe.. Indeed!

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

I agree. Now that we've all had time to look at the proposal, and
understand the underlying properties of whats going on here, its come to
light very, very early on that such functionality should NOT be tied to
the OS directly -- But rather, to top-level gear, a.k.a. the wm.

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

You can have both, but you'll lose visual consistancy from application to
application. It might be worth the trade-off.


(snip..snip) 
> 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")

Absolutely agreed. There should be (as you say) a standardized set of
common states an app can be in, at any one time. Man, i'm glad to see that
we're all arriving at the same logical conclusions here. 

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

Agreed.

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

Yup. Its even USEFUL feedback, ontop of that!

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

Well, to me, i'm a stickler for efficiency. A feature must justify its own
presence by providing information which makes any CPU penality worth it.
The addition of color-reactiveness to GNOME would easilly, easilly justify
its inclusion on sheer coolness, let alone the fact that its actually
conveying useful information to the user. :)


Bowie J. Poag