Menus in lower left corner WAS: Re: [PATCH] NSMenu patch version 2.

[Willem Rein Oudshoorn]

Fred Kiefer <FredKiefer@gmx.de> 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.