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

[raster redhat com]

On 20 May, Bowie Poag shouted:

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

nonono.. not what i meant.. the application ets a hint on its window
"i'm idle" beofr eit goes into its idel loop or when it starts
processing schanges the hint to "i'm busy" if tid wousloding as it goes
ti changes the hints to be "0%" "10%" "20%" etc... the widnow manager
will get an event every time these hints change.. ti sees a new app
state hint. it hen looks upt its own list of whihc icon matches that
hint number  (lets say 0 is clean, 1 is idel, 2 is busy, 3 is
downloading etc..) and thu all "busy" apps display the same busy
icon... all "idel": apps dsiplay the same idle icon. you have perfect
consistency.:)

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

Well it'll be in Enlightenment 0.14 - code is alreday sitting there..
:)  E read the hints currently.. doesnty do anythgin about them.. but
reads them.. :) gime a few days and it will be able to displayt he
state icon on the window border.. i have a mountian of other things I
have to do tho in the meantime.. its just on the list :)

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