Re: fun with window managers.. (help!)

[Havoc Pennington <hp redhat com>]

Bill Haneman <bill haneman sun com> writes: 
> I am running sawfish 0.36, which claims to respect WM_TAKE_FOCUS.  But
> it looks as though GDK maybe always calls XSetInputFocus() when it
> receives WM_TAKE_FOCUS, which is not what we want.  Furthermore I am
> warned that sawfish may not respect these settings if they are called on
> already-mapped windows, but it looks to me as though I can't set them on
> GDK windows unless they have already been mapped, since I can't change
> the initial property/flag settings on gdk_window_new(), can I ?

Basically all window managers I've looked at do not properly comply
with the ICCCM on this (i.e. they do not allow "output only"
clients). With a compliant window manager, the "xev" utility won't get
any key events. With most window managers it does.

Sawfish has a config option to make it ICCCM compliant in this
respect. I'm not sure what the default is.

For stay on top and such, you have a real dilemma. There are two
approaches. Approach one is to be an override redirect window and
monitor window stacking changes made by the window manager and other
override redirect apps, and try to keep your window in the right place
with respect to changes made by the window manager. This is basically
pretty broken, imagine two override redirect apps that monitor
stacking changes, and whenever another window raises they raise above
that other window. Note infinite loop. Not good.

Approach two, don't be override redirect, and rely on the window
manager to do what you want, which means relying on the WM responding
to specific hints/requests in specific ways. Unfortunately the ICCCM
does not guarantee enough about WM behavior. i.e. a fully
ICCCM-compliant WM could do things that are very much not what you
want.

I would expect that the "dock" semantic type in the new WM spec
(www.freedesktop.org), which will also be used for the panel, should
have the right semantics for your keyboard gizmo as well, with the
possible additional requirement that output-only clients never get
focus. There may be some extra details.

If you want I can try to prototype some behavior in Metacity and we
can work out what the WM should do, then we'll codify it in the WM
spec once it seems to work pretty well.

Havoc