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

[raster redhat com]

On 20 May, Bowie Poag shouted:
->  
->  
->  > 
->  > 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? :)

not a good idea.. program (app) design revolves aroudn the blocok
evenmt queue in most cases.. often an app will sit and simply wait till
somehting happens it isn't dead - its perfectly alive.. tis just quite
bored and waiting.. :) thsi is the "idle" state.. if an app u expect to
do somehting sits in an idle state you cna safely assoume its havign a
bad day.. apps that segfcault normally will exit immediately anyway..
if there is an error I have provided 2 error levels in the app states
for an app to, if whilst doign an operation anr error occurs (eg out of
disk space, network error, packet retransmission needed etc.).

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

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