Re: Incremental redisplay and output recording - revisited

• To: Robert Pfeiffer <rdp@netcom.com>
• Subject: Re: Incremental redisplay and output recording - revisited
• From: miller@cs.rochester.edu
• Date: Tue, 19 Jul 1994 12:46:44 -0400
• Cc: clim@BBN.COM
• In-Reply-To: <199407190248.TAA08090@netcom14.netcom.com>
• References: <199407190248.TAA08090@netcom14.netcom.com>

I think supporting simultaneous i/o (full duplex) is an essential
goal. I was under the impression that such an ability, as in emacs, was
designed in from the start, even if the 1.0 implementation didn't
support it. No?

We'd also like to have multiple output processes simultaneously updating
different panes while an input process gets input from the user. Getting
input shouldn't block the output processing (except, perhaps, for the
duration of a click, or while a menu is pulled the menu may not update).
Input may update what output will be displayed in steady-state. Input
may include gestures on presentations in one or more of the output
panes.

I too signed up for CLIM II, and I hope to hear how to go about this.

--
Brad Miller                    miller@cs.rochester.edu
Computer Science Dept.         http://www.cs.rochester.edu/u/miller/
University of Rochester        716-275-1118 (v) 461-2018 (f)
Rochester, NY 14627-0226

• Incremental redisplay and output recording - revisited
• From: Scott McKay <swm@harlequin.com>

• Incremental redisplay and output recording - revisited
• From: Robert Pfeiffer <rdp@netcom.com>

• Prev: Resizing a frame programmatically
• Next: Incremental redisplay and output recording - revisited
• Index: CLIM Mailing list (1-Jun-94 to 30-Jun-95)
• Thread: CLIM Mailing list Index (1-Jun-94 to 30-Jun-95)