Re: NET WM Spec implementation and changes

[Sasha_Vasko osca state mo us]

>On Thu, Jun 15, 2000 at 04:44:32PM +0100, Michael Rogers wrote:
>> > > Client programs shouldn't really request specific window manager
behaviours
>> > > like that. Users can request the behaviour through the window
manager if it
>> > > provides a "stay on top" option.
>> > >
>> >
>> > Why not? In my mind, almost everything that the user can do via
>> > window manager decorations and menus should be made available to
>> > external applications.
>>
>> The window manager is supposed to be in charge of policy, so that there
is
>> consistent behaviour on the user's screen no matter who wrote the apps.
>> Exposing the window manager's internals to other apps invites them to
implement
>> their own policy, because if the window manager can't distinguish
between a
>> "close window" command which was initiated by the user (via an external
app)
>> and one which was initiated by an app, it has to obey the command. So it
loses
>> control over policy and there is no way to ensure consistent behaviour.
>>
>
>The best a window manager can hope to provide is a consistent
>reponse to the demands made of it through events. X allows windows
>to perpetrate all sorts of things against other windows, and it is
>not the window manager's responsibility to decide which to accept and
>which to deny, or which come from users and which do not. Ill-behaved

That is exactly what window manager is supposed to do. It is free to
override
any request from client/user, based on WM configuration.

>programs will exist regardless; the point of the spec is to provide
>(hopefully well-behaved) programs with a wm independent way to meet
>their needs.

None of the clients should be able to override WM mandated policy. Thus
by giving clients too many options you in fact, give them nothing, since
it will be overriden by WM anyways. It will only create an illusion
and confusion. You have to be very carefull, in order to allow apps to
set only hints that do not imply any particular result, but simple inform
WM
about desired result. For example if you set window Type to be Modal -
that does not imply any specific reaction - it merely requests WM to treat
the window differently from other windows. How exactly it will be treated
-
it is up to WM. But when you set StayOnTop - this implies a very specific
reaction  - put window on top, and WM has no other option but ignore this
request, if it contradicts its own policy.

Instead of using "StayOnTop" it may be better to use term "Important", or
something like that, as it does not imply any specific reaction, but tells
WM that client would like to be as higher on stack as possible, but
whithin the WM mandated limits.

<snip>

>> > And if that information should persist across sessions, it is the
panel's
>> > responsibility to save and restore that property, not the window
manager's.
>>
>> It's the window manager's responsibility to save and restore window
geometry.
>> I would argue that things like stacking behaviour fall into that
category too.
>>
>
>If anything, I would say it is a session manager's responsibility
>to notify the app of a close/shutdown so that the app itself can store
>it's geometry (and whatever else it wants) so that it can restore it
>later.

The question is not about geometry - in which case you would be correct
and client should take care of it's own geometry, question is about
stacking order,
and it is not client responcibility at all to even approach this question,
or even be aware about stacking order at all.

>
>Jeff Raven

Sasha Vasko