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

Re: CLIM question

    Date: Wed, 22 Jul 1992 12:57 EDT
    From: gmw@cypress.mitre.org (Gregory M. Whittaker)

    I have been working with CLIM-2.0.alpha and just getting familiar with some
    of the basic properties of CLIM geometry. I don't know how much of what I am
    discovering is merely an artifact of the alpha version and how much is there
    by design. But my feeling is that there is an apparent effort to minimize the
    sophistication of the geometry model. My concern is that the geometry model
    will have very limited utility for spacial modeling and necessitate the 
    development of entirely parallel geometry models to do anything non-trivial
    in a mathematical sense. 

CLIM does not intend to provide any sort of a substrate for spatial
modeling.  CLIM is for building user interfaces, and as such CLIM's
interest in geometry is limited to the geometry necessary for describing
such interfaces.

Because one of the goals of CLIM was to describe appearances in a
device-independent manner, CLIM has more geometry (and is more careful
and explicit about it) than most user-interface languages.  This has
lead some people to believe that they were getting some sort of
geometric modeling capability "thrown in for free".  They were wrong.

    [...]

    I think it would be nice if rectangular polygons could be coerced to 
    rectangles at creation, since they are immutable and could logically be
    considered a subclass of polygon so that the test rectanglep would work
    on arbitrary rectangular regions and the rectangles would not be bereft 
    of the polygon protocols such as map-over-polygon-segments or map-over-
    polygon-coordinates.

I agree that rectangles should obey the full set of polygon protocols.

    Reading the beginning of section 3.2 Other Region Types in the 2.0.alpha
    documentation (from Franz) indicates that there is some sort of proposal
    to even further diminish the utility of regions by removing polygons, poly-
    lines, ellipses, and elliptical arcs. I certainly would like to hear the
    rationale for this; I think it would be a serious flaw and is a move in
    the wrong direction.

I believe the proposal is not to remove certain pieces completely, but
to have them available as optional add-ons.  

Any proposal to "demote" certain objects to optional status, or for that
matter to add on certain new classes of objects (e.g. splines), can only
remove (add) entire classes that are closed under affine transformation.
So you can't remove ellipses without removing circles.  Whether such a
stripped-down CLIM, whose only graphics were lines and points, would be
useful to anyone is an open question.  Perhaps a CLIM without any
graphics at all would be useful in some situations.

My own belief is that such a stripping-down procedure is more profitably
done at application-delivery time, by a "garbage-collecting linking
loader" or "tree-shaker".  Then you can strip out exactly and precisely
what your application doesn't need.  And you can strip it out of the
entire Lisp, not just the UI.
References:
Main Index | Thread Index