Re: who "cleans" windows on withdraw?
- From: Owen Taylor <otaylor redhat com>
- To: Matthias Clasen <maclas gmx de>
- Cc: wm-spec-list gnome org
- Subject: Re: who "cleans" windows on withdraw?
- Date: Sun, 28 Apr 2002 18:55:27 -0400 (EDT)
Matthias Clasen <maclas gmx de> writes:
> We somehow dropped this discussion. Is it concensus that the WM should
> clear _NET_WM_STATE and _NET_WM_DESKTOP when the client withdraws a
> toplevel, but leave them if the WM unmanages a toplevel because it is
> going down (or even crashing) ?
> This achieves that
> * legacy toolkits can reuse withdrawn windows without having them stick
> to their former desktops
> * WMs can be restarted without lumping everything together on desktop 0.
> * non-legacy toolkits which want to use the withdrawn state for hiding
> toplevels without iconifying them (like GTK does) must keep track of
> the last state and desktop and restore them before mapping the window
GTK+ has no fixed definition right now of what:
does, so I'm not sure that I'd say that it wants to restore
the window exactly as before; that would be one possible behavior,
but perhaps not the most useful one.
I'd tend to expect the window to come up on the desktop it would come
up when initially mapped, so this certainly supports cleaning
I'm pretty positive that the programmer didn't want a maximized window
to become a not-maximized but full screen, though, and I'd expect
that to apply to "legacy" toolkits as well, so I'm not sure
that cleaning _NET_WM_STATE makes sense.
] [Thread Prev