Re: NET WM Spec implementation and changes

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

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

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


Michael