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?