Re: Collating proposed changes to 1.9e

[Sasha_Vasko osca state mo us]

Jeff Raven writes :
>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.

I'm only objecting to idea of using StaysOnTop hint in this situation,
instead of more standard and politically correct way.

>> >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

Oh, yes there is. When you request raise for window - you do it without
changing WM's policy. But when you use StayOnTop you make WM to change its
policy. For example if WM employs layering - it will cause window to be
moved from layer to layer.

This example actually raises another problem with StayOnTop hint. What
window manager is supposed to do after app clears StayOnTop? Return to its
previous place ? That would be a nightmare, since you will have to
implement
sophisticated history tracking technique, thus overcomplicating WM design.
Things like repetitive requests to set StayOnTop will only make it more
difficult. Besides this sort of situation is not defined by specs and as
the result will lead to major difference in WMs behaviour, thus defying
idea of compatibility.

>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.

Why would not it? If WM rejects request - its only in accordance to policy
set by user.

>
>> 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.

That makes situation even more dangerous, since this scenario can occur
even if mouse was over the panel for long enough time to trigger raise,
but user clicks on other window right after moving off of the panel.
Panel will be waiting for delay before clearing StayOnTop hint, meanwhile
WM will override users request to raise the other window.

>
>> 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.

Simple raise request is supposed to be satisfied in accordance to
window manager rules, that are in turn, defined by user. So if user
explicitely
forbids window manager to bring panel on the very top, then you would not
want
to override it by setting any StayOnTop hints. Instead you would want to
bring
panel as close to the top as user wants it to be - which is exactly what
raise request is supposed to do. Again if window manager honors this
request -
then window will remain on top as long as user will not request WM to
bring some other window on top, window manager will not go around changing
stacking order just out of idle interest.

>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.

The only reason why applet may choose to rise window at any time is by
following request to do so from user, or some alarm. If user is still
interested in panel then he/she is not likely to request any changes in
stacking order that may cover panel. There is of course case when user may
want to circulate through windows, raising them up along the way, using
Pager/whatever, but that is rather limited case, and its not clear what
user really want - raise windows on very top, or leave them underneath of
the panel. Again in that case we are better off by leaving this to window
manager to decide.

>
>> 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.

This is very bad example. Approach of using StayOnTop hint to implement
'raise on mose-over' is incorrect and dangerous, and should not be employed
by any app, much less encouraged by specs.

Sasha Vasko