CLIM II draft specification available for comment

[Scott McKay <SWM@STONY-BROOK.SCRC.Symbolics.COM>]

CLIM II specification announcement
July 15, 1992

As indicated in a previous press release, Franz Inc., Lucid Inc., and
Symbolics Inc. are making available for public review and comment a draft
of the CLIM 2.0 specification.  The draft being made available is
Symbolics' May 6 draft of the CLIM 2.0 Specification, which is serving as
the starting point for the multi-vendor effort.  The document is intended
to specify both the application programmer's interface (API) for general
programmers and the lower-level protocols for programmers who are extending
or implementing CLIM.  The specification is available via anonymous FTP at:
ftp.uu.net in the file /vendor/franz/clim/clim.ps.Z, which is the
compressed postscript file (specify binary protocol to FTP).

Comments should be sent to CLIM-Spec@Riverside.SCRC.Symbolics.COM.
Please include appropriate page numbers with each comment.

The great majority of the open issues in the specification have been
resolved, but several sections of this draft are currently in dispute.  The
vendors believe that it is better to issue a complete, even if imperfect,
draft.  In some cases, a disputed section represents the solution that one
or more vendor favors.  In other cases, a disputed section is approved by
no vendor.  In all cases, we believe that comments from the user community
can help to resolve the disputed issues.

The remainder of this cover letter highlights the issues in the
specification that either require some further consideration or work, or
are the subject of active dispute among members of the CLIM coalition.
Some of these items may already be resolved in the current working version
of the specification and some are even noted in the May 6th document
itself.  We hope that this concise listing will help readers to focus on
disputes, while also allowing those interested in CLIM to focus on the
settled portions of the specification.  Note that this is only a terse
listing intended to give some sense of the scope of the problems rather
than a detailed discussion.  The chapter and section numbers listed below
are from the specification dated May 6.

  Chapter 3.  Geometry
    3.1 General Regions
    3.2 Other Region Types                          
      3.2.2 Polygons and Polylines                
      3.2.3 Lines                                 
      3.2.5 Ellipses and Elliptical Arcs          

The May 6 specification describes several regions classes (PATH, AREA,
POLYLINE, POLYGON, LINE, ELLIPSE, and ELLIPTICAL-ARC) that some members
feel are of marginal utility.  On the one hand, CLIM itself and may
applications do not use any of these classes.  On the other hand, there
is a family of applications (such as graphic editors) that do use these
classes.  Furthermore, to fully implement the geometry protocol (such as
transformations, point containment and region intersection predicates,
and so on) is not trivial.  One proposal under consideration is to move
these classes into an optional module that is not part of CLIM itself.

  Chapter 8.  Sheet Protocols                   
    8.4.1 Repaint Protocol functions                

One group working on the implementation of CLIM 2.0 re-implemented the
so-called "Silica" layer found in CLIM 0.9.  In doing so, the semantics
of the repaint protocol functions were changed in such a way that the
names are inconsistent with the input protocol functions.  For example,
HANDLE-REPAINT and HANDLE-EVENT are no longer analogous.  There is also
some question whether the current specification lets you mix queued and
immediate repaints properly.  There is no disputed issue here per se,
but this section will probably change in order to fix these problems.

  Chapter 9.  Ports, Grafts, and Mirrored Sheets 
 
This entire chapter will be rewritten in order to make it accurate. 

  Chapter 12.  Graphics                              
    12.6.3 Port-specific Drawing Functions     

The PORT-DRAW-xxx functions have been discarded in favor of folding that
layer into the medium layer.  The specification will be changed to
reflect this.

There are also no functions with which to query device characteristics,
such as resolution, color depth, and so on.

  Chapter 13.  Drawing in Color

There is a proposal to add a portable color map abstraction to CLIM,
which are called "palettes".  There is also a proposal to add "raster
colors", which can be used to more directly model "deep" color displays
with overlay planes.

  Chapter 13.  Drawing in Color
  Chapter 14.  Patterned Designs                  

These two chapters are based on CLIM 1.0's "design-based" drawing model.
Some members of the coalition claim this model is confusing and point
out that there is not yet a complete implementation that can justify it.
Supporters of the "design-based" drawing model feels that it reflects a
powerful, abstract, and portable graphics model that is consistent with
new trends in graphics on commonly available platforms.

A plan under consideration is to carefully recast Chapter 13 so that it
makes no references to the "design-based" drawing model, and recast
Chapter 14 to extend Chapter 13 to support the more advanced model.  A
conforming CLIM implementation would not be required to implement the
functionality described in Chapter 14.

  Chapter 15.  Extended Stream Output        
    15.3 The Text Cursor                   
      15.3.1 Text Cursor Protocol        
      15.3.2 Stream Text Cursor Protocol 

There is some question about the utility of advertising the cursor
protocol.  At the API level, cursor objects are not useful, but the May 6
document is intended to serve as a document for implementor as well, and
these people do need to understand cursors.  In any case, the
specification has holes in the protocol for dealing with multiple cursors.

  Chapter 16.  Output Recording                       
    16.1 Output Records
      16.1.1 The Basic Output Record Protocol     
      16.1.2 The Output Record "Database" Protocol        

There is a desire among all participants to unify some aspects of the
sheet protocol and output record protocol.  Doing so will cause most of
the functions in this section (and some of the functions in Chapter 7)
to be renamed.  For SHEET-ADOPT-CHILD and ADD-OUTPUT-RECORD might be
unified under the name SHEET-ADD-CHILD, SHEET-DISOWN-CHILD and
DELETE-OUTPUT-RECORD might be unified under the name SHEET-DELETE-CHILD,
OUTPUT-RECORD-PARENT would be renamed SHEET-PARENT, and so on.

  Chapter 21.  Incremental Redisplay      
    21.3 Incremental Redisplay Protocol        
    21.4 Incremental Redisplay Stream Protocol 

The specification of the incremental redisplay protocol is presently
rather dubious.  Proposals include completely rewriting the sections, to
discarding them from the specification entirely.  Unfortunately, there
is noone who thinks that the existing protocol is even the right thing.
The disposition of these sections remains cloudy.

  Chapter 22.  Extended Stream Input
    22.2 Extended Input Stream                      
      22.2.1  The Extended Input Stream Protocol  
    22.4 The Pointer Protocol                       

As with the cursor objects, some members question the usefulness of
advertising the pointer protocol.  There are also holes in the protocol
when it comes to dealing with multiple pointers.

  Chapter 22.  Extended Stream Input
    22.5 Pointer Tracking 

There is a minor issue regarding whether or not to use &KEY in the
TRACKING-POINTER clauses.  The open problem is that it may be difficult
to detect the incompatible change from CLIM 1.1.

  Chapter 22.  Extended Stream Input
    22.6 Gesture Preprocessing       

It has been suggested that gesture preprocessing be discarded, as there
are no contemplated clients of this facility.

  Chapter 25.  Menu Facilities                       
  Chapter 26.  Dialog Facilities                     

These chapters need to specify more about how they interact with
underlying gadget toolkits.  There have also been various requests for
additional functionality associated with the "exit boxes".

  Chapter 27.  Command Processing 
    27.3 Command Menus          

It has been suggested that something like the "menu groups" from CLIM
0.9 should be reinstated.  There is some dispute over the manner and
extent to which the menu group paradigm should be modified.  On the
other hand, some members claim that the :MENU option of command tables
fully subsumes menu groups.  If this is the case, it may be sufficient
to simply advertise the object used to represent the menu within the
command table as a "menu group".

  Chapter 28.  Application Frames                     
    28.2 Defining and Creating Application Frames   
    28.6 Examples of Applications                   
  Chapter 29.  Panes
    29.3 Layout and Layout panes

There are still some minor disagreements about the design of the pane
description language and the layout options.

  Chapter 28.  Application Frames                     
    28.4 Generic Command Loop

There is a proposal for breaking command loops down into their component
pieces so that they can be more easily tailored.  There is no
disagreement here, but the proposal is incomplete as it stands.

  Chapter 30.  Gadget Panes                           
    30.2.1 Using Gadgets

Some members dislike the new functionality of passing an optional
functional argument for the various callback when calling MAKE-PANE to
create a gadget.  Supporters feel this allows a programmer to more
easily and concisely customize callbacks for particular instances of
gadget panes without having to resort to EQL-specializing the identifier
argument for the various callback methods.