[mcclim-devel] incremental redisplay and with-first-quadrant-coordinates

[Robert Strandh]

Duncan Rose writes:
 > 
 > format-graph-from-roots et al (I'm thinking about draw-arrow, 
 > draw-oval...)
 > are purely convenience functions. I don't really view them as part of 
 > CLIM
 > even, except in as far as they're in the specification and so should be
 > implemented.

Hmm. What other definition do you have of "part of CLIM" other than
"they're in the specification"?  

 > Franz has the 'draw-bezier-path' method I think for this. Of course, 
 > this
 > is easy to implement for Beagle (since draw-line, draw-rect etc. 
 > collapse
 > into path based Cocoa methods - Cocoa is purely path based). I would 
 > guess
 > the math isn't that hard for generalised paths so I'd agree. But then, 
 > I'd
 > say this should probably be an extension too ;-)

I implemented this for Gsharp a while ago, and it was nontrivial to
get the rendering to be acceptable at the same time as keeping
performance reasonable.  The problem is that with the CLX backend, you
have to break down the curve into a polyline which takes time.

 > I actually think that the windowing (sheet, medium, mirror) and drawing
 > primitive parts (regions, designs, transformations) of the spec are 
 > pretty
 > good as they stand. (Pretty much?) everything else can be built on top.
 > I think that most limitations in the spec are in those other bits (but 
 > then
 > I know those parts least, so maybe that's coming from my position as an
 > observer).

The part of the spec concerning windowing and drawing is definitely
better than the rest.  But even in that part, there are
contradictions, big gaps, confused terminology, etc.  It would
definitely be good to start with that part and clean it up as much as
possible. 

 > Whilst I wouldn't propose that those higher levels of CLIM should be
 > removed, it is the drawing primitives and windowing that form the 
 > foundation
 > for everything else, and those are the bits that (I think) are the most
 > important to get right 

I guess so, but then they are also the ones that are the easiest to
get right. 

 > (note: this does include events).

and this is already nontrivial, because it includes things like
support for different input methods for different languages, support
for extended character sets like Unicode, etc. 

 > There's a lot of work involved if we want to see the CLIM spec reworked 
 > to
 > be anything like as complete as the CL spec, I agree. But then I don't 
 > think
 > that is needed (it would be nice).

Believe me, it IS needed.  The spec is full of things like this: 

   \Defgeneric {process-next-event} {port \key wait-function timeout}

   This function provides a standard interface for one pass through a port's event
   processing loop.  \arg{wait-function} is either \cl{nil} or a function of no
   arguments that acts as a predicate; it has dynamic extent.  The predicate should
   wait until one of three conditions occurs:

   \begin{itemize}
   \item If an event if received and processed, the predicate should return
   \term{true}.

   \item If a timeout occurs, the predicate should return \term{false}.

   \item If the wait function returns \term{true}, the predicate should return the
   two values \term{false} and \cl{:timeout}.
   \end{itemize}

Now, after reading that, please tell me which one is the predicate:
process-next-event or the wait-function?

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------