Re: Collating proposed changes to 1.9e

[Jeff Raven <jraven psu edu>]

On Fri, Jun 30, 2000 at 09:29:10AM -0500, Sasha_Vasko@osca.state.mo.us wrote:
> >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.
> 
> Is'n it the whole idea of 'raise on mouse-over'? Panels comes up for
> short period of time while mouse is over it, and then gets obscured
> again, when mouse moves off of it? Panel should be able to raise itself
> up simply
> by using XConfigureWindow with stack_mode = Above, and sibling = None.
> Window manager will intercept this request and fullfill it as best as it
> can.This is the way prescribed by ICCCM. That should be perfectly
> sufficient for 'raise on mouse-over'.
>

When I mean 'briefly on top', I mean until the window manager
stacks any windows, since any stacking by the window manager
results in the panel being covered. (Reasons why this may happen
are mentioned below.) Anyway, the point is moot since the intent
of that passage was to describe the current behavior.

> >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 surely is not the right way, since panel will have to set and unset
> this hint on each EnterNotify and LeaveNotify thus creating lots of
> unneeded overhead, and potential for conflicts when mouse is only briefly
> moved over the panel.
>

There is not much difference in overhead between setting the hint
on mouse-over, and sending ConfigureRequest events. They will both be
used by the window manager to perform a restacking. The only problem
is that a simple raise will not necessarily have the desired effect
of making the panel visible.

> Consider scenario when some other window is
> partially obscured by the panel, and user moves mouse over the panel and
> onto that obscured window, and the clicks on it, wishing to raise it on
> the top. In this situation probability of window manager receiving
> EnterNotify and ButtonPress from the second window, prior to receiving
> message from panel that it may not be on top now, is very high. If that
> happen user will not see expected result, as panel will remain on top
> obscuring the second window.
>

Any code which relies on EnterNotify's to perform _any_ possibly
inconvenient action should _always_ use a delay during which a
LeaveNotify can prevent the action. So the panel would not raise
on a brief mouse-over. And if it were raised, it would lower itself
shortly after the mouse left the panel anyway.

> like I said the only correct way to achieve short term raise of window
> is using XConfigureWindow. If Window manager ignores this request, then it
> will ignore all the raise-related hints, unless it is really dumb.
>

The only correct way _without_ a provision in the spec for an 'on top'
hint is to use a ConfigureNotify event. My very point is that an 'on
top' hint would add a far better way to do it. The intent of raise-on
mouse-over is to bring the window to the _top_, where it can be easily
used. This is not necessarily what a simple raise message will result in.

Furthermore, if the panel cannot specify that it should be on top,
then any applet which allows the user to manipulate the stacking order
(a taskbar or a pager) could easily raise a window over the panel while
the user is still interested in it.

> long term configuration of any particular app to stay on top is much
> better handled by window manager configuration based on window title/class.
>

But this has nothing to do with the current example, since the intent
is for the panel to be on top only when it contains the mouse. I choose
this example for exactly that reason.

Jeff Raven