Re: NET WM Spec implementation and changes

[Jeff Raven <jraven psu edu>]

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

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

But configuration based on window type is insufficient. It will simply
encourage applications to lie about their window type in the hope that it
will give them a better chance of getting what they want.

Window type should only provide a base policy which can be subsequently
modified by user and application demands.

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

Jeff Raven