Re: NET WM Spec implementation and changes

[Sasha_Vasko osca state mo us]

>On Thu, Jun 15, 2000 at 10:00:20AM -0500, Sasha_Vasko@osca.state.mo.us
wrote:
>>
>> 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 not to create such a
>> confusion, since like I said, if window manager supports this
>> functionality ( which is not all that easy to implement BTW) it
>> MUST have its own options for that.
>>
>
>Any app which intends to offer any of these configuration options
>(whether OnTop, Sticky, etc.) should check to be certain that the wm
>supports it beforehand. Any app which does otherwise is just plain
>broken.

Question is not about the case when WM does not support it, but about the
case
when it is configured DIFFERENTLY in app config and WM config. Which one
takes
precedence in this case? How to let user know that there is a conflict?
If this is not supported by WM then this option is useless. If it is
supported by
WM it makes much more sense to configure it through WM, since it can
provide some
additional WM - specific extensions, like ability to choose from several
different layers, thus rendering client side option completely useless.
In addition to being completely useless it is also dagerous, since it fools
user
into illusion that app config overrides WM config, and therefore leads to
frustration when this expectations are not met.


>>
>> 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.
>>
>
>At present bbkeys (as well as bbpager, the Blackbox pager) is a
>Blackbox specific app simply because the wm spec is not yet
>finalized. However, both apps only require features of the existing
>spec to function, and are intended to work with any spec-compliant
>wm.

So in order to make bbkeys work with any WM you want to give the power
of overriding WM policy to any client app? Besides how bbkeys is supposed
to work with other window managers, if those window managers will have
their
own keyboard handling code? If Blackbox needs bbkeys - then just add
Blackbox specific extensions to it. No need to wreck a havoc and confuse
ppl
with conflicting configuration options.


>Jeff Raven