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

Questions...

    Date: Tue, 28 May 1991 15:40 EDT
    From: Bryan Basham <basham@aio.jsc.nasa.gov>

    Hello CLIM World,

    My programming team has been evaluating CLIM (Symbolics' 1.0
    rerelease) for a couple weeks, and we have a couple of questions:

    1) What does the PRESENT method default to?  Does it use
       PRINT-OBJECT?  How does this relate to lower-level printing
       functions and the format directives?

The present-method defined for type: T and view: TEXTUAL-VIEW calls
WRITE, though through a somewhat roundabout fassion.  I think WRITE will
eventually call PRINT-OBJECT where appropriate.

The PRESENT and ACCEPT methods for a presentation type serve to
"translate" back and forth between an object (the one being presented)
and some visable representation of the object (for example, a textual
representation like that produced by PRINT-OBJECT).  If the PRESENT
method (for a given presentation type and view) produces some text
representing an object, it is important that the ACCEPT method
(applicable to the same presentation type and view) be able to translate
that text back to the same object that was presented.  For most
application objects, this requires "naming" them somehow and
internalizing those names in a table.

If you rely on PRINT-OBJECT to do the work of your PRESENT method and
the printed representation of your objects is not READable, then you
could wind up in trouble when you try to ACCEPT them.


    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?

See the documentation for CLIM:DRAW-ICON.

A taxonomy of designs?  Are you looking for more detail than that
provided in the documentation section "Concepts of Designs in CLIM"?


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

I'm not sure, but I don't believe this is supported.  I think that the
construction of output histories is in some ways affected by the stream
to which output is performed.


    4) Has anyone implemented a MAC-like metaphor: select one (or more)
       item, then issue a command from a (pull-down?) menu?  For example,
       (using a MAC case) use sh-Left to select (and highlight) several
       documents in Finder; then select the Open command from the File
       menu.  This does not appear to be supported in CLIM as more than
       one object can be selected to issue multiple commands at once.

I'm not aware of one, but it is easy to imagine how to go about it.
First you need to maintain a list of the objects to be acted upon by the
next operation.  You need a command which adds an object to that list of
it is not present and removes it from the list if it is.  Third, a
presentation translator from the :select gesture (or whichever one you
like) to the command which maintains the argument list.

This approach has the disadvantage that since the operation is not known
at the time of argument collection, it can in no way affect the
selection of arguments (by specifying which kinds of objects it wants to
operate on) through the use of input context.


    Any help is appreciated.

    Thanks, Bryan

    /-------------------------------------------------/
    /  Bryan D. Basham				  /
    /  NASA/JSC  Mail Stop: ER22,  Houston TX  77058  /
    /  (713) 483-2065				  /
    /  basham@AIO.JSC.NASA.GOV			  /
    /-------------------------------------------------/

0,,
Follow-Ups: References:
Main Index | Thread Index