Re: [Usability] window manager configuration

[Jamie Zawinski <jwz jwz org>]

Havoc Pennington wrote:
> 
> 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.

Well, it depends on the design of the program, but if I were writing a
presentation program, there would be "editing mode" and "playback mode".
Editing mode would be in a decorated, potentially-full-screen window,
with popup dialogs and whatnot; and playback mode would take over the
whole screen, just like xscreensaver does.  Presumably, then, gestures
to bring up dialogs would drop you out of playback mode and into edit
mode, causing the window to switch from override-redirect to managed.

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

There exists a *very* small class of applications that need to
commandeer the whole screen: screen savers, presentation programs,
DVD players, and *possibly* *some* games.  In my opinion, the needs
of these programs are well met by override-redirect.  When you're
in a situation where your goal is "get the window manager out of 
my way", it's best to do that by simply not involving the window
manager at all, rather than by using some new protocol to negotiate
with it and *ask* it to please get out of the way.

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

Yes, and I think that presentation programs, movie players, etc. have
modes where they want to behave the same way.  They don't want to behave
like that *all* the time, but some windows in some modes do.

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

I'm all for having a utility function like that in GTK.

But, stepping back to the WM protocol issue -- let's say I'm writing a
program in who-knows-what toolkit, and I have the need to take over the
screen all the way to the edge of the glass.

What incentive do I have to use your new WM protocols to do this,
instead of just using override-redirect?  What benefits do I derive?
Because I don't see any benefits, only potential instability.

-- 
Jamie Zawinski
jwz jwz org             http://www.jwz.org/
jwz dnalounge com       http://www.dnalounge.com/