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

Questions...

    Date: Tue, 28 May 91 14:40:31 -0500
    From: Bryan Basham <basham@aio.jsc.nasa.gov>

    2) The term "bitmap" does not appear in the Symbolics' CLIM 1.0
       documentation.  Can bitmaps be implemented in CLIM?  Are they
       some type of "design" or "pattern"?
       In a related, but more general, question: is there a taxonomy of
       designs?

What do you mean by "bitmap"?  Several people have asked for off-screen
bitmaps/pixmaps that they can draw on, and be able to transfer rendered
images between these and the screen.  A reasonable name for this concept
is bitmap medium or pixmap medium.  Then there are 2d arrays/rasters
which are the actual pieces of backing storage for these, and they could
in theory be first-class CLIM objects.  Patterns, icons, stencils, and
images are reasonable names for this, but sometimes there are different
semantics (e.g., an image or icon gets drawn in a place, but a pattern
or stencil might tile the region with phase coherence).  Which of these
features do you really want the most?

    3) Is it possible to move an output history from one application
       window to another?  Can histories be stored without being
       displayed?

Output histories generally contain information that is specific to the
medium on which it was rendered.  The clearest example is rendering
text, where text styles map to device fonts which have different sizes
on different media.  So in practice moving an output history between
different types of underlying media has pitfalls.  In theory it is
possible to move a history between media that have the same underlying
rendering parameters, but this isn't well supported yet.  Another
(thought about but unimplemented) possibility is a draw-output-record
graphics operation that will redraw (and presumably re-record) an output
record on a stream.  Using this, it should be possible to copy (instead
of move) an output record from one application window to another.  Even
this can't be guarenteed to work correctly because the original
rendering may hae had some set-cursor-position operations in it, and the
semantic content of those cannot be recreated.

All that said, my guess is that you have a single instantiated
application with many window panes, and you want to move a
history/record from one to another.  That is a desirable feature, but I
don't think it is fully supported today.

Histories can be stored without being displayed, see
with-output-to-output-record.  Another possible answer is that you can
use with-drawing-options to turn of display, in which case the output is
stored in the current history, but undisplayed at this time, but it will
be displayed upon refresh (e.g., by scrolling).

0,,
Follow-Ups: References:
Main Index | Thread Index