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

[John R Sheets <dusk smsi-roman com>]

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.

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.

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.

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.

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.

John

raster@redhat.com wrote:
> 
> On 20 May, Tom Tromey shouted:
> ->  >>>>> "Raj" == Raj Dutt <rdutt@voxel.net> writes:
> ->
> ->  Raj> Firstly, I think putting the responsiblity with the window
> ->  Raj> manager is a good thing (tm).
> ->
> ->  Why?
> ->
> ->  My first reaction whenever I see a proposal to put something into the
> ->  wm is to reject it.  My reason is that there are many window managers,
> ->  and everybody has his own preference.  It's better to keep wm
> ->  requirements as small as possible, and put extended functionality into
> ->  a new program.
> 
> well how you expect to display this information in the border of a
> window, titlebar or in the icon of an iconified window beats me if you
> aren't going to use the WM... :) We could clutter up the panel and use
> corba and shit.. oh joy! WATCH the bloat as everypone needs to write c++
> wrappers for their code just to talk to mico. :)
> 
> For some people, like me, the panel is a temporary fix until I get my
> buttons, strips and stripjoints up and running in E. Once that happens
> It's use will become redundant and it can cease eating up skads of
> useful screen realestate. :)
> 
> ->  Then we have control over the program, and we also don't require a
> ->  weird setup.
> ->
> ->  Think of it like requiring something to be added to everybody's text
> ->  editor, or everybody's mail reader.  It just doesn't happen.
> 
> Maybe things are changing compared to how thingsa used to be written..
> u'll be surprised. 2 WM's already are putting this in - and its less
> than 48hrs later :)
> 
> ->
> ->  Tom
> ->
> ->
>