Re: Collating proposed changes to 1.9e

[Sasha_Vasko osca state mo us]

>On Thu, Jun 29, 2000 at 09:28:29PM -0400, Havoc Pennington wrote:
><snip>
>>
>> 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.

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

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

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.

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.

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

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

Desktop Documentation WILL have to include reference to window manager's
stacking order management functionality, since if window manager supports
this hint it MUST have some configuration options of its own, that covers
this area. I hardly envision a general purpose window manager solely
relying on hints listed in this specs. So user WILL have to go and read
window manager documentation NO MATTER WHAT YOU DO. Trying to cover up
window manager's configuration is like hiding your head in the sand.

>
>Jeff Raven


Sasha Vasko