Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!ncar!boulder!stan!marvin!garya
From: garya@marvin.Solbourne.COM (Gary Aitken)
Newsgroups: comp.windows.x
Subject: Re: OSF statements about OPEN LOOK
Message-ID: <1990Sep26.004756.4993@Solbourne.COM>
Date: 26 Sep 90 00:47:56 GMT
Sender: news@Solbourne.COM
Organization: Solbourne Computer, Inc.
Lines: 37

> In fact, any Window Manager involvement (as long as popup is an override
>      shell) is undesirable.

> The window manager must know about the (menu) shell. This means to
>        redefine the meaning of an Override Shell, or some other type of shell 
>        KNOWN to window manager must be used. This implies a slowdown on popup 
>        activation.

Not necessarily.  It depends on how the unpinned object is implemented.  The
unpinned object can be an override_redirect window, while the pinned object is
not.  I'm not saying I think this is the best implementation, but it works.
Part of the problem is that you would like a pinned object to be manipulatable
via the window manager (e.g. you would like to be able to move it), whereas
this is not the always case for the unpinned object.  For example, an unpinned
popup menu has no need for move/resize via the WM, but an unpinned dialog box
does have a need for this.  Thus, OPENLOOK popup menus in the unpinned state
are override_redirect, and the pin is owned by the client; but unpinned 
dialog boxes in the unpinned state are not override_redirect, and the pin is
owned by the WM.  If the pushpin were located anywhere but in the header
it would be great to have the client own them all the time; but since the
spec puts them in the header, the WM pretty much has to own them some of the
time.  We have menu pushpins which are, in fact, owned the whole time by the
client, and it is an annoyance because it is hard to grab the border to move
them with the WM; you really would like to grab them in the title area.

> A new protocol must be added to notify the application about the fact
>        that a menu has been "pinned down". This is not a MUST, (may be the
>        application should wait for Unmap events), but being
>        an application writer, I would like to know about the fact that my
>        popup remains UP, and my XtPopdown or Unmap request has been IGNORED

Yes and No.  The protocol must be defined so the toolkit (assuming you are
using one) can maintain state info, but from the application writer's point
of view, this shouldn't matter.  Since the application writer has no control
over the pinned/unpinned state (the user controls it), the application must
be written in a manner which will work whether the object is pinned or not.
If the toolkit handles it properly, you never look at pushpin state.