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

changing layouts

    Date: Fri, 5 Jun 1992 08:19 PDT
    From: Chris Elsaesser <chris@starbase.mitre.org>

    Dear CLIM,

    In Genera 8.1 CLIM 1.0, every time I do a 
       (clim::set-frame-layout <frame> <layout>) 

    from a command (e.g, com-foo), everything that follows the call
    to clim::set-frame-layout is ignored.  What am I doing wrong?


    chris



This came up before and Scott McKay gave a workaround (his message 
is included below).  I've used his first workaround with success.  
I have not tried his second.

David Bushnell
bushnell@eos.arc.nasa.gov




>From:  Scott McKay <SWM@sapsucker.scrc.symbolics.com>
>Newsgroups: ri.clim
>Message-ID:  <19346@ptolemy-arclan.ptolemy-ri.arc.nasa.gov>

In article <19346@ptolemy-arclan.ptolemy-ri.arc.nasa.gov> Scott McKay <SWM@sapsucker.scrc.symbolics.com> writes:
> 
>     Date: Mon, 25 Nov 1991 10:51 EST
>     From: curt@eraserhead.Jpl.Nasa.Gov (Curt Eggemeyer)
> 
>     I am on a SPARC in Allegro w/ CLIM 1.0.  I have an application frame
>     with two layouts (Normal, and Editor).  I have been doing some
>     experimentation with swapping layouts in an application via an
>     application command.  The first problem I have notice is that if you
>     have a command like.
> 
> The implementation for changing frame layouts in CLIM 1.0 is badly
> designed.  The issue is that, after the layout of a frame is changed,
> CLIM needs to recompute the values for the standard stream bindings
> (*STANDARD-INPUT*, *QUERY-IO*, etc.)  When you call SET-FRAME-LAYOUT,
> CLIM throws to the tag CLIM::RESYNCHRONIZE in order to recompute these
> values.  There are two workarounds:
> (1) If you know that none of the standard stream bindings will change
>     or don't care, you can do this:
>     (CATCH 'CLIM::RESYNCHRONIZE
>       (SET-FRAME-LAYOUT <frame> <layout>))
> (2) Alternatively, you can try installing the following kludge fix to
>     SET-FRAME-LAYOUT, until I figure out a better fix:
> 
> (in-package :clim)
> (defmethod set-frame-layout ((frame application-frame) new-layout)
>   (setq *frame-layout-changing-p* t)
>   (with-slots (current-panes initialized-panes) frame
>     (setf (frame-current-layout frame) new-layout)
>     (layout-frame-panes frame (frame-top-level-window frame))
>     ;; Forcibly display any panes that have not been displayed yet
>     (dolist (pane current-panes)
>       (unless (member pane initialized-panes)
> 	;; Display the pane and mark it initialized
> 	(redisplay-frame-pane frame pane :force-p t))))
>   (unless (eq *application-frame* *default-application*)
>     (setq *standard-output* (or (frame-standard-output frame) *standard-output*)
> 	  *query-io* (or (frame-query-io frame) *query-io*)
> 	  *standard-input* (or interactor *standard-output*)
> 	  *error-output* (or (frame-error-output frame) *error-output*))))
> 
>     (define-my-application-command (swap-them-back-and-forth :name t) ()
>        (set-frame-layout 'Different-Layout)
>        (sleep 10)           ;plenty of time to swap them panes around!
>        (set-frame-layout 'Original-Layout))
> 
>     The command will only do the first set-frame-layout.  My interactor pane
>     that is included with both layouts is still active though.  So if I use
>     a different command that just does (set-frame-layout 'Original-Layout),
>     I can get back to my original layout.  Why can't I swap more than one
>     layout within the same command??????
> 
>     The second problem I am having is that within the same application
>     command, when I swap layouts I cannot do output to the newly exposed
>     pane of my new layout (even with force-output).  However, If I put the
>     same code in a different command and then invoke it after invoking the
>     command that swaps the layouts , the output will appear on the newly
>     exposed frame.  Why can't I output within the same command when I swap
>     layouts?
> 
>     In my case I am trying to setup up a single command in which the person
>     invokes a multi-page editor on a presentation object that is in a
>     timeline like display.  I would like to do this in a single step.  But
>     right now the only way to get it to work is invoking three commands
>     (when I should be able to do it with only one)!  Is there something
>     trivial that I am missing?
> 
> Yes, but the trivial thing is not documented.
References:
Main Index | Thread Index