Re: Collating proposed changes to 1.9e

[Sasha_Vasko osca state mo us]

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

ordinary raise within the layer is done by single request just as raise on
top :
XRestackWindows. But you are saving on 2 property updates and one more
message to unset the hint. And this two things are much more cumbersome,
since updating property will trigger reaction from other clients.
>
>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.

Like I said - not really, since property update also triggers a reaction of
other clients.

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

You cannot return it to default layer, since window may have been  already
moved from layer to layer by user.

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

It will not fail to do so - it will simple follow the rules set
in window manager configuration. panel will get raised only in limits
designated for it by user in wm config.

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

Panel will not get itself out of the way - thats the whole problem.
It will only unset StayOnTop hint, But window manager will not lower it
untill some other client will not be raised, or user explicitely requested
to lower the panel.

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

Window manager may allow placing panel on any particular layer that is
not the top layer. If window manager supports StayOnTop kind of
functionality it must provide some sort of options to know which
clients are StayOnTop and which ones are not. So StayOnTop hint changeble
by client will be redundand and only cause confusion for user, as I have
explained many times already.

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

It will not be untill something else is explicitely raised on top of it,
and since StayOnTop hint may be cleared too late - such explicit request
may be ignored if it came too soon, thus leaving user pondering as
to what happened, and why the hell he has to wait timeout after he
moved off of the panel before he can actually raise something above it,
and why the hell panel went above other windows which user explicitely
requested to be always on top in wm config.

Again, timeouts are only a drawback, but the major problem is confusion
between conflicting configuration options in WM and clients.


Sasha Vasko