Re: Collating proposed changes to 1.9e

[Jeff Raven <jraven psu edu>]

Sasha_Vasko@osca.state.mo.us wrote:
> >> 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.

In which case an ordinary raise would result in more computational
and communication complexity, since it would require the window
manager to position windows so that all those which should be above
the window still are. Meanwhile raising the window to the top layer
would only require a single XRaiseWindow.

Now, I'm sure one can concoct situations in which setting the 'on
top' hint would be more complicated than a simple raise. But in either
case the difference is typically neglible, since the main cost comes
from whether a window manager supports the very concept of layers, and
any such differences would only come from optimizations of special
cases.

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

Huh? The window manager would just return it to whatever layer is
the default for that window type -- precisely the same method the
window manager used to place it the first time. I fail to see how
this forces the need for any 'history tracking'.

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

If the user has set the panel to raise on mouse-over, then if it
fails to become visible on a mouse over it is failing to behave
according to the policy set by the user. That is why an 'on top'
hint would be useful here.

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

Who said anything about the wm overriding the raise? The wm would
raise the window just fine; it would simply be raised in whatever
layer it was in. Once the panel gets itself out of the way, the user's
window will be topmost (at least in its layer). I'd hardly call that
dangerous -- the window will be exactly where the user expected it to
be.

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

If the window manager happens to provide a configuration option
'Keep windows of type DOCK from ever being on top', and the user
opts for it, the window manager can feel free to ignore the panel's
request to be on top. Though frankly I have no idea why a window
manager would provide such an option.

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

For many users, the taskbar/pager is one of the main reasons to
use a panel. And if the raise-(on top)-on-mouse-over feature is
in effect, they simply need to move their mouse a few pixels and
the panel will be out of the way.

Jeff Raven