Re: NET WM Spec implementation and changes

[Sasha_Vasko osca state mo us]

>>
>> Actually this is true. If window manager allows for such functionality -
>> it is likely to have it's own configuration option for that. So adding
>> StaysOnTop to specs makes it unclear as to what option should take
>> precedence.
>>
>
>I'm not sure what the problem is here... if an application specifies
>StaysOnTop, it should stay on top. If in the future the user should use
>wm functionality to turn off the StaysOnTop, the window mangager is
>obligated to update the STATE property. There should never be a conflict
>between what the STATE property says and the current behavior, so there
>is no question of precedence.

Ok here is the example :
Lets say compliant application A has a configuration option "Always on
Top",
User sees it and says to himself " Oh that would be cool!" and goes ahead
and enables this option. At the same time he has a window manager config,
where he/she requested some specific layer for that kind of clients, which
is
not the top-level layer. User then expects to see application to pop up
on top of everything, and is very disappointed when Window Manager
overrides it and puts it somewhere in the middle of the stack. Althou minor
amount of users may actually go and investigate and adjust WM config,
majority
of the users will just say : "Ah! That app is screwed!" or "This WM
sucks!",
or even "Hell! That Open Source software really sucks!".
This is how it goes usually, and there is nothing you can do about it.

Accordingly it would be muuuuuuch better notto create such a confusion,
since like
I saaid, if window manager supports this functionality ( which is not all
that easy
to implement BTW) it MUST have its own options for that.

>> That might be a good idea to make this option read-only, so that client
>> cannot request to StayOnTop, but it could find out if window manager has
>> put it on Top.
>>
>> Same thing applyes to Sticky, Shaded, and SkipTaskbar.
>>
>
>Unfortunately this removes some rather useful functionality. For
>example, at present blackbox has passed the responsibility of keyboard
>shortcuts to an auxiliary program (bbkeys). Via bbkeys the user can
>establish whatever shortcuts they would like, including ones to shade
>and stick windows. I expect tasklists/pagers would also like the ability
>to control these things.

ok, bbkeys is BlackBox specific app, therefore it can use some
BlackBox specific extensions of the protocol in order to achieve that. I
bet
it is going to do that anyways, since this specs are far too short then
what
is needed in order to implement fairily complete window manager
keyboard functionality.

>Jeff Raven

Cheers
Sasha Vasko