Re: [Usability] window manager configuration

[Havoc Pennington <hp redhat com>]

Jamie Zawinski <jwz jwz org> writes: 
> Presentation programs aren't normal programs; they don't want window
> management at all.  I think for presentation programs to work at all,
> they *have* to be using override-redirect windows anyway, so they're
> going around the window manager and it's irrelevant.

Things are also broken if you make a presentation program override
redirect. For example, you can't properly handle managed dialogs that
need to popped up on top of it; the window won't have the
Alt+rightclick window menu that many window managers have; the Alt+Tab
window-switching API is mangled.

We need to be thinking in terms of how to eventually get things really
right, which means sorting out how to actually convey information to
the window manager. We can still think about backward compat in that
framework, of course.
 
> I can't even imagine the world of hurt I would have been in had I tried
> to allow the xscreensaver window to be window-managed.

xscreensaver's a somewhat different case, in that it "takes over" the
whole display and you are never working while it's up.

> You could try to define some new hint that says "hey window manager,
> please behave as if I'm override-redirect", but why?  Anyone who is
> writing a program that needs to do full-screen undecorated stuff is
> gonna write that program as override-redirect anyway, because they can't
> count on that hint being obeyed, and it's a critical requirement, not
> just something that "would be nice."

What we have in the new EWMH spec is a way for clients to tell whether
the window manager supports certain hints. Then we abstract things on
the widget toolkit level. This is pretty similar to how X extensions
let us add X features without breaking apps.

So for example if a window manager supports the new _NET_ACTIVE_WINDOW
client message we activate windows that way, if it doesn't we have a
fallback hack that doesn't work quite as well or reliably, but is at
least as good as whatever apps would have tried to do historically.
This is all buried inside gtk_window_present().

That gives the best of both worlds - we can move forward, but apps are
still as compatible as possible.

For the presentation app, we'd probably have
gtk_window_make_fullscreen() which does its best to give you the
undecorated fullscreen window deal.

Havoc