Re: Sawfish/Gnome/Xinerama dropping windows

Scott Anderson <ee_in_co yahoo com> writes:
> I put the information from xwininfo and xprop below.  xwininfo
> reports that the first gnome-panel window is unmapped with override
> redirect state no.  xprop reports the WM_STATE property is not
> found.

So that one is withdrawn.  As it is only 10x10 pixels, it is probably
a dummy window for storing some properties, never intended to be

> The second gnome-panel window is also unmapped with override
> redirect state yes and WM_STATE is not found.

That one is not managed by the wm because of override redirect.  It is
also kind of small and the location is rather strange.  And it is
saved under.  Might be a tooltip or something like that.

> Just making sure I understand so far, this means the windows were
> unmapped.  Does unmapped mean closed?

Sort of.  In terms of window management, a toplevel window can be in
one of three states: withdrawn, normal and iconic (window management
only applies to toplevel windows).  For the X server, there are just
two states: mapped and unmapped.  Of the wm states, normal is mapped
and the other two unmapped.  Withdrawn windows are unmapped because
the client does not want to display them.  They are essentially
invisible to the user.  Iconic windows are unmapped because the wm
does not want to display them, typically due to the user's request.
There is usually some visual representation of an iconic window, such as
a taskbar entry.

With Sawfish, windows may be in the normal state yet unmapped because
they are not on the current desktop.  That seems to be a bug, because
windows unmapped by the wm should be marked iconic.  It is unlikely
to be related to the current bug though, as panels are usually sticky.

> We don't know if the unmapping was caused by the client (which is
> gnome-panel in this case) or some bug in sawfish?

The 10x10 window is probably not intended to be mapped in any case,
and Sawfish should not have touched the other window at all because of
override redirect.  It seems you are looking at the wrong windows.

> Once a window is unmapped, there is no way to map it again?

It can be mapped, but if the client has unmapped the window, no one
else should map it.  The client does not intend the window to be
visible and may not be prepared to draw its contents or handle events
related to it.

> So at this point I should restart gnome-panel and wait for the next
> occurence.  What information would help us learn more the next time?

It might be useful to examine its window structure under normal
operation and compare with the messed up state.  An xtrace of it
getting messed up would be nice, but that may be difficult to arrange
if it only happens rarely.

	Timo Korvola		<URL:>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]