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

[Miroslav Silovic <silovic zesoi fer hr>]

I like color reactiveness a lot, and I pestered Raster to add hue
shifts to Imlib on a few occasions. There are a few notes, though:

Bowie Poag <bjp@primenet.com> writes:

> A: "The code responsible for color-reactiveness can (and should) be
>     tied directly to /proc, or something which watches /proc for you.

This is absolutely unacceptable, as GNOME is supposed to be portable
(not all unices have /proc, and those that have (Solaris) don't use
the same format).

Lamps and beacons (if I understand them correctly) are tied to windows
and their icons. This means that they should fall under Window
Manager's jurisdiction. From there, there are a few things to do:

1) WM hints: Application should be able to send its status to WM as one
   of the extra hints. This, in fact, is a great idea regardless of
   whether it's used for color reactive desktop elements or some other
   way of status displaying. So, the question to then WM team: would
   it be feasible to add WM hints that allow the apps to tell their
   activity status to the WM - WMs can implement it later at leisure.
   Thing is, the idea if 'activity' varies with the application, so
   each should be able to implement its own idea of tracking (within
   some sort of standard guidelines).

2) default behaviour: Noncompliant applications won't set their hints.
   There is a question of default, in that case: the problem is that
   network apps would be active/inactive depending on their I/O status,
   while CPU bound apps would be active if OS isn't swapping them too
   much. I think the reasonable default for color tracking WMs would
   be CPU usage reported by gtop library, but for now, gtop isn't
   portable. Or just colormark only the apps that ask for it.

3) gmc: I could think of a few ways to colorize (or beaconize) icons
   withing the file manager - by filesize, or age.

-- 
I refuse to use .sig