CLIM mail archive
[Prev][Next][Index][Thread]
Incremental redisplay and output recording - revisited
Date: Tue, 19 Jul 1994 12:46:44 -0400
From: miller@cs.rochester.edu
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?
"No" is the correct answer.
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.
You can do this by implementing locks on the appropriate panes. This
is a case where a small fraction of applications require this, but if
CLIM supported it itself, everyone would have to pay for it.
On the one hand, everybody wants CLIM output to be very fast. On the
other hand, some people say they want to add more stuff to the lowest
levels of CLIM that would impede performance in the usual case while
at the same time not providing any benefit for most users. In
situations like this, I always opt for the higher-performance choice.
I too signed up for CLIM II, and I hope to hear how to go about this.
References:
Main Index |
Thread Index