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

[Bowie Poag <bjp primenet com>]

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

Very true. However, the wm can be told to -expect- periodic "updates" from
the application in regards to its status. If no updates are recieved
within a certain timeframe, the program is assumed dead, and its lamp will
be changed accordingly. See, we can work around that problem without tying
it directly to the OS, or to /proc. It can still safely remain a function
of the wm. Ain't it great? :)

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

Im sure it would be possible -- But, would it be neccessary, if the same
functionality can be tied to the wm instead?

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

Color-blindedness was an issue we dealt with in InSight when developing
this idea. We batted the idea around of having shape differentiation in
addition to color change, but we eventually elected that the visual
consistancy of the lamp was more important. Besides, with the Color
Transition Table, users who know they are colorblind can simply alter the
appearance behavior of paticular states to fit their needs accordingly.

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

A) Thank you. :)

B) Tying it to /proc, although the most obvious solution, may not be the
   best in the long run due to the fact that /proc (or even /proc
   equivalents) do not exist on other platforms. If it were an ideal
   world, I would push for tying color-reactiveness directly to /proc, or
   a suitable /proc watchdog -- However, it seems the more viable solution
   to this problem is to handle the task within the confines of the wm.


> Matt Briggs <mbriggs@switchboard.net>
> 

Bowie J. Poag