Re: [RFC] Menus in lower left corner, possible patch

[Willem Rein Oudshoorn]

Michael Hanni <michael@deviant-behavior.com> writes:

> However, your ideas here reminded me of something I read once on the web and
> after some digging I came across the X function that may help out:
> XWithdrawWindow.
> 
[Quoted documentation removed]
> 
> If I switch XUnmapWindow to XWithdrawWindow in XGServerWindow (orderwindow:) I
> can scroll up and down the menu without getting permanent hanger ons in the
> bottom left corner. They do flicker to life down there but are almost
> instantaneously unmapped.

Hm, I do not trust this.  When I was looking at the problem I noticed
that the menu appeared in the lower left corner becuase it got
a Reconfigure Event while it was mapped but it should not have been mapped.
So it seems there is still a problem with this.  If it is in GNUstep or 
in X I can not say yet.
 
> Anyhow, you shouldn't withdraw all windows, but perhaps this will help you on
> the right path...

Why not?  From reading the discussion you digged up it seems
the preferred way of unmapping toplevel windows, and DPSorderWindow 
call deals only with toplevel windows.

(Thanks for the link, when I searched in google I could not find
anything relevant.  It is nice to see that my guess coincides with
their analysis)


[Quoted from another e-mail:]
> I went fishing in the usenet archives at google and pulled this out:

> "An excellent analysis of the problem.  I would ony add this:

>How to fix this: First, issue your MapWindow request, then flush the
>client's request buffers by calling XFlush(). After that, wait for a
>MapNotify event or an Expose event to be sure that the window has been
>mapped, and only *then* issue your UnmapWindow request.

> There can be circumstances in which this will wait for ever, notably if the
> window is transientfor an iconified main window.

Not a good idea.  Is very hard to get right and as long as I can not find
a foolproof way of matching the MapNotify to the XMapWindow request I
prefer the hack solution.

> p.s. check gdkwindow-x11.c in the gtk+ sources for an example.

I am going to look at it.  Hopefully I get a tested fix out
by the end of the week.  

Wim Oudshoorn.