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

[Bowie Poag <bjp primenet com>]

On Fri, 22 May 1998, John R Sheets wrote:

> What I get from this whole discussion about color reactiveness
> and where to put it and how far to implement it/control it is
> that GNOME could benefit from a simple, extensible status
> messaging protocol.  If a WM wants to implement an app's status
> as a lamp or beacon, fine.  If it wants to use icons, sounds,
> animations, or tap into some central default (theme-based?) GNOME
> status-drawing API's, then fine too.  The important thing is the
> status messaging.

Agreed. However, conceeding this, we shoudln't throw the baby out with the
bathwater. The best way to implement an "extensible status messaging
protocol" is via the use of lamps, beacons, and color-reactive elements.
Only in special cases (such as in color-blindedness) should other
methodologies be explored. There needs to be a standard; not only for how
the idea is to be implemented, but also a standard for visual continuity,
IMHO.

And as you point out, the wm should shoulder most of the burden for this
activity. Back-engineering apps is simply out of the question. The
original proposal was written so that nobody would *have to* back-engineer
their apps in order to take advantage of color-reactiveness. It works out
great for everyone.

> 
> It seems that the best way to implement this is to allow the
> application to broadcast (asynchronously) whichever (if any)
> messages it wants, to e.g. the WM.  If the WM is GNOME-ified,
> then it will pick up the status and do whatever it wants with
> them (supposedly within the bounds of the standard GNOME styles);
> otherwise it will just ignore the status.  And secondly, provide
> a standard interface (CORBA?...) within the application for
> status polling (synchronous) from the outside, e.g. the panel,
> applets, the WM, and other applications.  Thus, the application
> doesn't have to broadcast its state constantly to everyone, yet
> anyone can check it out from time to time if they want.
> 

Ahh.. Smart idea. I like the two-headed approach you've described here,
not so much in terms of its inherent flexibility but by virtue of the fact
that it would take almost no additional CPU to add that kind of
functionality to the wm, i'd imagine. (Correct me if im wrong, someone..)

:)


> The best of both worlds.  I don't think we need to skew the
> reponsibility entirely toward the WM, or toward the
> applications.  Distribute the load and make it optional.  If a
> given WM doesn't want to handle status, don't force it to; but
> allow alternate ways for the user to get that info.

Exactly.

> 
> I don't know much about X-Windows communications/interactions
> yet, but would it be possible to delegate the drawing of the
> status elements (lamps, beacons, etc) to some external,
> centralized place?  It'd sure be nice to be able to change the
> status indicators of ALL your app's in one fell swoop.  This
> would be a perfect candidate for themes, wouldn't it?  If you
> don't like LED's, you can switch to traffic signals, or bar
> graphs, or jungle sounds, or growing bonfires, or whatever.  This
> would take care of the color-blind/B&W monitor problem: just find
> a theme that is shape-oriented.
> 

Agreed. Thats the point behind Behavior Sets, and the control panel
describption given in the proposal. There needs to be a way to allow the
user to arbitrarrily select the behavior and appearance of n-reactive
elements. 'n' does not exclusively have to mean *color* , although its of
my opinion that its the best way of conveying status. As you point out,
shape could also be an important indicator for those who are dissatisfied
with color. 

The good thing is, when you get down to the root of it, the only thing
changing hands within the wm when it comes to color-reactiveness are
simple icons. These icons can be anything, of course, not the least of
which are simple colored bulbs. The flexibility of the concept is
limitless.

> Color-reactiveness is a good idea, but it's only one idea in a
> potentially long list of equally good *other* ideas.  We should
> keep things open, and not implement our way out of including
> these other ideas (whatever they may be) down the road.
> 

I say, implement one, make room for the others. The guidelines listed in
the proposal, if followed closely, will enable future expansion and
extensibility of the design to happen with ease. I like the idea of Themes
as well.

> John

Bowie J. Poag
bjp@primenet.com