Re: Collating proposed changes to 1.9e

[Jeff Raven <jraven psu edu>]

On Thu, Jun 29, 2000 at 09:28:29PM -0400, Havoc Pennington wrote:
> 
> Jeff Raven <jraven@psu.edu> writes:
> > The KDE folks, at least in their draft implementation, seemed to be
> > in favor of it. Do they still feel that way, and does whoever is on
> > the GNOME library side of things have an opinion?
> > 
> 
> Typically when we are sitting around Red Hat Labs going "should we add
> feature foo to GTK", we ask what the use cases of the feature would be.
> 
> What sort of window would use the stay on top hint? A splash screen
> maybe? That sounds like a likely one.
> 
> If we can think of legitimate uses for the hint, we should have it.
> 
> Havoc
> 

Hmm. Here's another one : It would provide a 'nice' way for panels/docks
to raise themselves to the top.

Case in point : The gnome panel provides a 'raise panel on mouse-over
option'; at present this can lead to inconsistent behavior, since the
panel sets itself up as an unmanaged window. This means it can easily
raise itself on top, but the window manager can just as easily cover
it up; so while it may briefly end up on top, it may not stay there
for long.

The intent of the spec, I suppose, is for things like panels to become
managed windows (just with a special window type), in which case the
previous self-raising shenanigans would be prevented by the window
manager, since it would keep the panel below any windows that the user
had marked OnTop. This would mean, barring impolite behavior on the
panel's part (which would interfere with the window manager's ability
to track the stacking order), an OnTop hint would be the only way for
a panel to implement 'raise on mouse-over'.

It also allows panels/docks to be configured to stay on top through
their own configuration menus, rather than forcing the desktop's
documentation to cover the mechanisms used by all the common window
managers.

Jeff Raven