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

["Robert J. Slover" <robert slover rose-hulman edu>]

Greetings,

Regardless of whether Tom read the whole thread, he made a good point
that I don't think should be missed.  Tying this function into the WM
(at least directly) may not be the best approach.  At the bare 
minimum, I think the functions to read and write these window manager
hints should be generalized enough that the programmer should not be
thinking about supplying hints to the WM, just expressing the state
that his program is in.  Later, if a gnome event service materializes,
the functions to set hints can be gutted and rewritten to post an event
to the service, and the functions to get hints can be gutted and 
rewritten to retrieve states from the event queue.  This wouldn't break 
anything that already used the hints, and would expose them to more
listeners.  Besides, not every application one runs has a window
to set hints on!  What if I wanted an indicator that told me how heavy
my apache server on the box was getting hit?

So, with that in mind, I'd like to see a layer of indirection in
Raster's code (a wrapper) to retrieve state transition hints.  I'd
like to see this wrapper (and corresponding wrapper functions to set
the hints from an application) end up in the gnome gui library with
no indication that a Window Manager is involved.  Later, the X calls
to get/set hints on the window can be replaced with more general ones.

Just a thought.

--Robert

Bowie Poag wrote:
> 
> On 20 May 1998, Tom Tromey wrote:
> 
> > Bowie> B) Tying it to /proc, although the most obvious solution, may
> > Bowie>    not be the best in the long run due to the fact that /proc
> > Bowie>    (or even /proc equivalents) do not exist on other platforms.
> >
> > You can't use /proc because it isn't network-transparent.
> > People can, and frequently do, run X applications over the network.
> 
> I'll refrain from writing any replies to that assertion until you can tell
> me whether or not you've actually read the initial proposal in detail. If
> you'll pardon me for saying, it seems to me that you haven't. We've
> already moved past this point in the course of discussing the initial
> proposal.
> 
> For GNOME's purposes, reliance upon /proc (or a /proc daemon) is out of
> the question since it breaks portability between platforms. Other OS's
> have /proc equivalents, where still others dont even have anything
> resembling /proc at all.
> 
> Bowie J. Poag
> 
> >
> > Tom
> >
> 
> Bowie
> 
> --
>          To unsubscribe: mail gnome-list-request@gnome.org with
>                        "unsubscribe" as the Subject.

-- 
------------------------------------------------------------------------
 Robert J. Slover | Admin Sys Mgr | Rose-Hulman Institute of Technology
------------------------------------------------------------------------

 "Yesterday starts tomorrow, Tomorrow starts today.  The problem 
  always seems to be we're picking up the pieces on the ricochet..." 
                                                    -Marillion, "Jigsaw"