Re: who "cleans" windows on withdraw?

[Cristian Tibirna <tibirna kde org>]

On Sunday 03 March 2002 23:43, Havoc Pennington wrote:
> Hi,
>
> We have several properties that are taken as the initial state when a
> window is first mapped, then kept updated with the current state by
> the window manager.
>
> e.g. _NET_WM_DESKTOP.
>
> Some apps open a dialog, and when the user closes the dialog the app
> just withdraws it, and next time the user opens that dialog the app
> maps it again.
>
> If no one does anything special then the dialog has _NET_WM_DESKTOP
> set on the second map, which means that it will come up on its old
> desktop, not on the current active desktop.

KWin sets the _NET_WM_DESKTOP  to 0. Doesn't touch NET_WM_STATE, reparents the 
window to the root, then deletes its info from its internal structure info,  
sets a nomask on it for the events and then invalidates the window.

>
> If the window manager clears _NET_WM_DESKTOP when unmanaging windows,
> then restarting the WM or switching WMs has the unfortunate side
> effect of dumping everything onto desktop 0.

? The windows are unmapped. How could they start to the desk 0. Even at the 
restart, they have to get managed first, and they will not be shown (nor on 
desk 0 nor anywhere) until a remap request is done by the parent (as I get 
it, we discuss about child dialogs here).

And when such a dialog is remapped, it should definitely get the desktop of 
its parent (aka, probably, the current desktop, not the desk on which the 
dialog was when withdrawn).

> If the toolkit has to clear _NET_WM_DESKTOP on window unmap then
> there are issues with legacy apps not doing so, probably.
>
> _NET_WM_STATE has the same problem.

Definitely. Even worse, some apps change this while dialog is hidden. E.g., 
buggy sun jdk-1.3.1, is setting an IconicState on the hidden dialogs, _after_ 
the window manager had set them to withdrawn upon hiding request from the 
parent.

So, he got plagued for some time by the ugly bug that java apps weren't able 
to display a dialog more than once, short of recreating it each time from 
scratch (i.e. hidden dialogs got iconic state that kwin was interpreting 
literally upon remap, thus making necessary for the user to minimize-maximize 
once its app in order to get the dialog shown). Now we fixed this. A child of 
a NormalState window can't get mapped as Iconic. (Bug was also fixed on the 
jdk side with sun-jdk-1.4)

> It seems to me that having the WM clean up windows when unmanaging
> them is probably best, and perhaps for a clean WM restart a WM could
> have a special mode where it didn't clean things.

We do the first. And for the dialogs we shouldn't care for the second.

> But I'm wondering what other people are doing or expecting here.
 
Hope I answered satisfactorily.

-- 
Cristian Tibirna .. tibirna sympatico ca
PhD Student .. ctibirna giref ulaval ca .. www.giref.ulaval.ca/~ctibirna
KDE contact - Canada .. tibirna kde org .. www.kde.org