Re: NET WM Spec implementation and changes

[Jeff Raven <jraven psu edu>]

On Wed, Jun 14, 2000 at 05:05:20PM +0100, Michael Rogers wrote:
>  > Well, the problem is that either the client program or the user may
> > want a window to stay on top even if the window type does not default
> > to that behavior. Furthermore, external programs should have some way
> > of affecting this (see below).
> 
> 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.

> > Of course, since honoring STATE is not mandatory, the window manager
> > is free to clear the StaysOnTop bit and manage the stacking order
> > however it wants using the TYPE information. (Though personally I'm not
> > convinced that TYPE_DOCK should necessarily mean that the window should
> > be on top.)
> 
> No, it shouldn't be used for that. It should mean "treat this window like you 
> treat other docks". WHat that means can be user-configurable (in the window 
> manager) or the wm can use a sensible default.
>

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

> > > 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.
> 
> Oh no, BlackBox doesn't depend on the 1.9e spec does it? Does bbkeys send 
> client messages to the root window to change the state of other clients' 
> windows?
> Why use a standalone app for hotkeys BTW?
>

No, at present blackbox does not depend on the spec. Given the
pace the wm spec was moving at, it wasn't practical to wait for it
to be finalized. But yes, it does send client messages to the root
window to change the window manager's handling of other windows.

As for why one would use a standalone app... In order to be assured
of not interfering with the functioning of client windows a window
manager really must make any shortcuts easily and completely
configurable. This ends up adding so much to the wm itself it might
as well be a seperate app.

Jeff Raven