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

["Matthew R. Briggs" <mbriggs switchboard net>]

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

Matt Briggs <mbriggs@switchboard.net>