Re: Repairing damaged application panes

• To: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
• Subject: Re: Repairing damaged application panes
• From: kanderso@BBN.COM
• Date: Wed, 26 Aug 92 14:09:36 -0400
• Cc: pkarp@Sunset.AI.SRI.COM, York@lucid.com, halverson@crd.ge.com, clim@BBN.COM
• In-Reply-To: Your message of Wed, 26 Aug 92 10:21:00 -0400. <19920826142140.8.SWM@SUMMER.SCRC.Symbolics.COM>

  Date: Wed, 26 Aug 1992 10:21-0400
  From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
  Subject: Re: Repairing damaged application panes
  To: pkarp@ai.sri.com, York@lucid.com
  cc: SWM@stony-brook.scrc.symbolics.com, halverson@crd.ge.com, clim@BBN.COM
  
  
      Date: Tue, 25 Aug 1992 18:34 EDT
      From: Peter Karp <pkarp@ai.sri.com>
  
      I would like to argue for a mechanism that allows repair of damaged
      panes, that is independent of the event loop.  People here complain
      that if an application prompts the user with a menu, then computes
      for a while, then goes back to the event loop, that a damaged region
      persists during that computation and looks ugly.  If you know a large
      amount of computation is about to occur, it would be nice if you
      could force repairs to occur.
  
  Call REDISPLAY-FRAME-PANE, or (in CLIM 2.0) REPAINT-SHEET.

When, where?

This problem has plagued us on certain x servers.  The x event loop queues
the repaint event for after the command is over, as described above.  This
makes a hardcopy-window command impossible.  If you forcefully do the
repaint while the window is drawing for the first time, you can get very
strange results.  The x event process and the frame process need better
coordianton.

k

• Re: Repairing damaged application panes
• From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>

• Prev: clim contrasting colors
• Next: Re: accepting-values pane (CLIM 1.1 Genera 8.2)
• Index: CLIM Mailing list (1-Jan-92 to 31-Aug-92)
• Thread: CLIM Mailing list Index (1-Jan-92 to 31-Aug-92)