Re: A Proposal For The Addition Of Color-Reactiveness To The GNOME Desktop
- From: raster redhat com
- To: mbriggs switchboard net
- cc: bjp primenet com, silovic zesoi fer hr, gnome-list gnome org, gnome-gui-list gnome org
- Subject: Re: A Proposal For The Addition Of Color-Reactiveness To The GNOME Desktop
- Date: Wed, 20 May 1998 16:45:58 -0400 (EDT)
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]