Fred Kiefer <[EMAIL PROTECTED]> writes: > Hi Wim, > > menus kep on appearing in the lower left corner for me as well. It > would be great if you could resolve this problem quickly.
I think I know what the problem is and I don't like it. After tracing x11 section in Back I discovered that: * The menus are ordered out and in correctly * In some rare occasions the XUnmapWindow call is ignored. Now I have a theory why this is happening, and why it happens rarely and that menus are prone to this behaviour. Sequence that will lead to NOT unmapping window (theory) -------------------------------------------------------- A - XMapWindow (..., WINDOW) B - WINDOW is toplevel window, now this request is redirected to the window manager. C - XUnmapWIndow (..., WINDOW) D - X server notice that the window is not yet mapped, the request for mapping is somewhere in the window manager and not honored yet. Not that the X server cares, it sees an unmap request on an unmapped window so it will DROP the unmap request. E - The window manager finally gets around considering the request and it will map the window. F - `back' gets an MapNotify event. And nicely draws the window. End situation: WINDOW is mapped, but should not be mapped. NOTE: Because there are at least two eventqueues involved, just flushing after the XMapWindow/XUnmapWindow will NOT work. (BTW The current implementation already flushes the X queue). Supporting evidence ------------------- I ran Gorm.app with: * fvwm * sawfish * windowmaker * without a window manager. In the first three cases I managed to reproduce the bug. In the fourht case I did NOT manage to reproduce the bug. When does this happen --------------------- >From the description above it should be clear that this can only happen when a window is mapped in and out in quick succession. Also, it should be mapped by `back'. If someone else maps our windows (like the windowmanager) there should not be a problem. Possible solutions ------------------ * Make sure that on NSMenu's the override_redirect flag is TRUE. This should prevent the windowmanager from interfering. I have to read again in my Xlib programming manuals to see if this should be done through hints, or when we create the menus. Problem with this solution: - It does NOT solve the underlying problem for NON menu windows. - We do not know in `back' if something is a menu and so we should apply this to all borderless windows. - This will hamper moving NSMenu's by means of the the windowmanager. * Fix the underlying problem in `back'. This is tricky. A simplistic approach would be to wait in DPSorderwindow until a map / unmap request is honoured. However, this requires a method to match MapNotify events to be matched to a particular MapWindow request. Otherwise we will not be solving the problem, only making it more unlikely to appear. At the moment I have the feeling that this is not easily solvable without reverting to dirty hacks, and even then it might be impossible. Plan ---- I will read up on some X-programming techniques and think about a general solution. If that fails I will probably add a new NSWindow style: `Transient' which will be set by the NSMenuPanel and honoured by `back' to set override_redirect. Any comments? Wim Oudshoorn. _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep