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

[Bowie Poag <bjp primenet com>]

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

Agreed. Portability must come before feature. Gladly, this doesn't torpedo
the whole concept of color-reactiveness. It only eliminates the
possibility of tying CPU usage (specifically) to the Lamp, or Beacon --
Only as minor point. 


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

Exactly.

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

Agreed. These standard guidelines could also be considered part of the
overall behavior set defaults, set up ahead of time.

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

Makes sense. Their placement on the desktop matters little, but the
ability to differentiate between several beacons is very important. For a
short while in InSight, we toyed around with the idea of a "Task Pocket"..

Kinda like the Finder menu on a Mac, but dynamic..A drop-down menu of
tasks which you have elected to wad up and put in your pocket, along with
their current color status displayed in a lamp next to their name:

p----------------------------q
| Pocketed Applications..  |?|  Each currently "pocketed" app appears in
+-+--------------------------+  the menu, with its lamp on the left. If
|O| Netscape FTP Download #1 |  you want to pop an app back open, select
+-+--------------------------+  it from the list, and it appears on the
|O| RC5/DES II Client        |  desktop. Its also removed from the menu
+-+--------------------------+  until the user re-pockets the app.
|O| XTerm (kernel compile)   |
+-+--------------------------+  Get it?
|O| Netscape FTP Download #2 |
+-+--------------------------+  We eventually elected to scrap the Pocket
|O| Netscape FTP Download #3 |  idea, because we thought it took too much
b=+==========================d  from the Mac's Finder menu, and because

we already had a task monitor/switcher on the drawing board already. The
idea later evolved into Beacons. Same thing, really, just autonomous and
not contained within a menu for the user to select from.


Bowie