On Tuesday, June 28, 2005, at 03:18 pm, Robert P. Goldman wrote:
"DR" == Duncan Rose duncan@robotcat.demon.co.uk writes:
DR> On Tuesday, June 28, 2005, at 01:37 pm, Paolo Amoroso wrote:Robert Strandh strandh@labri.fr writes:
[...snip...]
DR> Perhaps I'm missing something fundamental regarding thefacilities DR> offered DR> by other systems, I just can't think of much that needs adding DR> to CLIM.
This is perhaps off the topic a bit, but I think the graph-formatting facilities could use an overhaul. They don't seem to have been written with much of an eye to permitting extensions (e.g., format-graph-from-roots doesn't have &allow-other-keys).
I'd agree, but I'm not sure extending format-graph-from-roots is the best way to achieve it. To be honest I'm not really qualified to put forward a suggestion since I don't really know enough about different kinds of graphs.
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.
Another thing I'd like to see is some support for curved lines in the drawing layer. Franz CLIM seems to have this.
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 ;-)
Any work we would do towards an extended CLIM should be thought about carefully wrt what is fundamental, and what's an extension. We should provide a sensible place for extensions to be placed (there are a couple of extensions in the code already; personally I don't think that putting them in the same file as code that's implementing specified methods is correct, but I'm also a big fan of 'put them where it's convenient, and tidy up later').
DR> I think we'll just need an additional chapter or two rather DR> than a new spec. - this is the benefit of starting with a DR> 'mathematically complete' specification in the first placeOuch. I'm not sure I'd go THAT far. Stacking the CLIM spec up next to the CL spec does not make for a comparison that is to the advantage of the CLIM spec... I don't mean to complain --- obviously there were far fewer resources to throw at the CLIM spec --- but I wouldn't call it complete.
I was referring to one of the 'issue' points in the spec, namely that some people want to remove ellipses etc. and the point made there that the drawing primitives are mathematically complete. Perhaps my tongue was in my cheek, who knows? ;-)
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).
Not wanting to bang on about DUIM all the time, but presentations etc. are not supported out of the box there; I believe SM did build presentations on top though.
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 (note: this does include events).
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).
Often my comments make more sense to me as I write them than they do (even to me) when they're read ;-)
-Duncan
Best, R