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



On 20 May, Matthew R. Briggs shouted:
->  Bowie Poag wrote:
->  
->  > >
->  > > Um.. I think we need a much more precise definition of "status" before
->  > > anything like this can be done... is statuse just running or not? is it
->  > > running, waiting for somehting, sleeping, awating input, ... ? this
->  > > would be best done by property hints... can be implimented in a flash..
->  > > if I just know what there is...
->  > >
->  >
->  > Whenever I speak of "status" , i'm referring to the total number of
->  > possible states a program can be in, both physically at the process level,
->  > as well as at the operational level. "Status" means everything from "idle,
->  > sleeping, running, or zombie" to "rendering.. , busy.. , checking email.."
->  > etc.. Any state to which a program can be in, at any time. Whatever is
->  > most important to the user to see reflected in a Lamp, or in a Beacon.
->  >
->  > Think of "status" as a general, all-encompassing thing. Here's another
->  > example  -- Me. Right now, my status is that i'm sick with the flu. I'm
->  > also busy writing this email. I just ate, so i'm no longer hungry. All of
->  > these things are different states -- Bowie is Sick, or Bowie is Busy,
->  > Writing, Hungry, whatever.
->  >
->  > Hope this helps.
->  >
->  > Bowie J. Poag
->  >
->  > --
->  >          To unsubscribe: mail gnome-list-request@gnome.org with
->  >                        "unsubscribe" as the Subject.
->  
->  Hello,
->  
->  One thing that occurred to me that nobody else has mentioned is that sometimes
->  a program might not be able to report its own status to the WM (which would
->  handle the lamps or beacons).  If an app crashes or freezes (as has been known
->  to happen on occasion), the WM will not be notified, and the status light may
->  cheerfully and erroneously glow green, or blue, or whatever.
->      The original proposal called for using /proc, which would have provided
->  information about the execution status of a process, at the cost of being
->  non-portable.  Is there any potential for using some derivation of the
->  recently-announced libgtop to overcome this problem and implement this
->  innovation?

there is no way to knwo an app has crashed from any proc info.. if the
rpcoess crashes the process dies and goes away - its windows aswell -
if ti gets in an infinite loop and doesnt update  /proc can onyl tell
us the process is eating cpu.. we don't know something is wrong... if
its sitting on a blockign read or write.. we cant knwo tis crashed.. it
could be designed to do that... :) that is the reason in my firm code
proposal all states have 2 versions.. every half second swap between
them to "flash" to show "awakedness" if you wish to do that (as an app)
if it's needed.

->      Finally, to overcome the color-blindness issue (which I agree is
->  important), since the proposed beacons and lamps would use pixmaps anyway, why
->  not use a colored letter or symbol?  A yellow triangle, a green circle, or a
->  red octagon (a universal symbol, no?), for example.

thats exactly what I said.. it provides more versatility, better
customisabily and configurability, and more simplicity.. :)

->      I think the color-reactiveness idea has enormous potential, but it will be
->  most effectively implemented if it is independent of the code for each
->  application, hence the use of /proc or its equivalent.  What do you think?

see the prevois wad of code I posted for a conctrete proposal to
impliment this in real code.

->  Matt Briggs <mbriggs@switchboard.net>

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