Re: NET WM Spec implementation and changes

["Michael Rogers" <mrogers cs ucl ac uk>]

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

> But if it is user configurable it should be so on a per client basis.
> And per client configuration is often most naturally handled by the
> client. If I want a panel to always be on top, I should be able to
> use the menus provided by the panel to set that (especially since
> most panels request that they receive no wm decorations, and thus it
> can be difficult to access the window manager functions).

The point of _NET_WINDOW_TYPE hints is to allow you to configure the way the 
window manager treats all panels, or all dialogs. This just seems like a 
natural way to express policies, and it means when you install a new app it 
will behave like your existing apps straight away - you don't have to go 
rooting around in configuration dialogs to find out how to ask it to keep its 
dialog windows pinned to its titlebar or whatever. Per-client configuration is 
still possible, via the WM, but you get sensible default behaviour if you can't 
be bothered to do per-client configuration.

You don't need window decorations to do configuration based on window type, 
because you don't configure a specific window, you configure a class of windows.

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


Michael