CLIM mail archive
[Prev][Next][Index][Thread]

Your suggestions on popup windows

    Date: Wed, 6 Oct 1993 12:36 EDT
    From: fleming@mickey.jsc.nasa.gov (Land Fleming)

    (I am working on a Symbolics running Genera 8.3).

Thanks.

    I'm not sure what all the :PARENT keyword did in open-window-stream in
    CLIM 1.1, but one thing was to automatically size and position the
    window to be the same as the parent application pane when the size and
    position arguments were omitted in the function call.

Hmm, I didn't know CLIM 1.1 had this sizing/positioning behavior.  My
guess is that that behavior is accidental.  At least OPEN-WINDOW-STREAM
let you specify the size and position yourself...

    Based on your earlier message I tried the following:

    (let* ((top.sheet (frame-top-level-sheet application))
           (pallette (open-window-stream :SAVE-UNDER T
                                         :INPUT-BUFFER (stream-input-buffer top.sheet)
                                         :PORT (port top.sheet) 
                                         :RECORD T :SCROLL-BARS :BOTH)))
      (setf (sheet-event-queue pallette) (sheet-event-queue top.sheet))
         

    The window created in this way (the "pallette") still gets buried as
    soon as I click on a "real" application pane. It made no difference
    whether I used the :INPUT-BUFFER argument instead of or in addition to
    setting the sheet-event-queue of the window (these seem to be the same
    thing).

I see.  OK, this is Genera's window manager screwing you.  You might be
able clobber the underlying window directly to get the Genera parent
relationship set up right.  I'll have to think about this.

    In CLIM 1.1, I used these popup windows for several reasons, but the
    purpose here was to provide a pallette (hence the name of the variable)
    of command presentations.  I used popup windows to save screen real
    estate.  There are several different pallettes that are stacked over
    the same (blank) application pane, and the user switches between
    pallettes by clicking on a command menu. The blank application pane was
    the :PARENT argument in CLIM 1.1, and the popup windows were
    automatically sized to cover it completely.
 
I see.  This is an unusual strategy, but it doesn't seem unreasonable.
As I said, this will require a bit of thought.

    Each presentation was a graphical depiction of an object class, and the
    associated command created an instance of the class depicted. The tricky
    part here is that part of the command sequence involves moving the
    mouse pointer over a real application pane, where the user indicates the
    position of a presentation for the new instance by clicking a mouse
    button again. A copy of the pallette's graphical depiction of the class
    is made at the point clicked on (we are talking CLIM 1.1 here, so the
    drawing functions are called; copying from a pixmap is one of the
    changes I want to make to take advantage of CLIM 2).

    The behavior of temp windows under CLIM 2 apparently won't support this
    kind of interaction. If you can think of any way to do it, I would still
    be interested. I think, however, I will just have to make the pallettes
    permanent panes in the application - either that, or give each popup
    pallette its own application pane. Implementing a command that involves
    user interaction with several different applications as well as
    different windows is a little complicated, although I believe it is
    doable. I know it involves detecting the frame the mouse pointer is
    currently in and setting the globals that are normally set by
    run-frame-top-level (*application-frame*, *standard-output*, etc.) to
    the appropriate values for the current frame.
References:
Main Index | Thread Index