On Wednesday, June 29, 2005, at 05:43 am, Robert Strandh wrote:
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"?
Basically, the primitive drawing / windowing / io methods. This is probably because I only work on back end stuff at the moment.
I think I have a different working definition of 'extension' to other people; for me an extension is anything that's built on top of other bits of CLIM (this view does reduce the amount of information that needs to be thought about from a back end perspective; everything can be classified as 'needs back end method implementation' or 'does not need ...', with all the 'does not need ...' methods being extensions).
I would hazard a guess others have an inverted view; CLIM is, pretty much, all that higher level stuff and the primitives are there only to support *this* CLIM functionality (and are therefore not really CLIM - they're Silica).
In truth its all CLIM of course (I know this; I just tend not to spend that long thinking about non-silica things at the moment. I expect this to change in the not-to-distant (but seemingly ever-receding) future).
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.
It sounds to me like this then is the kind of functionality we *should* be adding to CLIM; stuff that, whilst possible for an application developer to write, is sufficiently non-trivial that a 'standard' implementation would be valuable.
It also sounds like it's already written and just needs rolling into the McCLIM code base proper?
Personally I'm less interested in a performant implementation than I am in a correct API (definition of correct: allows the control points to be specified and a performant implementation to be written, in this case). I'm subscribing to the 'get it working, then make it fast' philosophy.
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.
Indeed.
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?
I think they're both predicates in this context; the value(s) returned from the 'outer' predicate depend on the results of the 'inner' predicate if it's supplied.
I agree that this is poorly worded. Whether a note as to how it's implemented in McCLIM, or a whole respecification of the functionality is needed is not so clear to me. Perhaps there's no difference (specification sounds so much more formal (and final) than 'implementation note').
-Duncan
-- 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.