"DR" == Duncan Rose <duncan@robotcat.demon.co.uk> writes:
DR> 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 the >> facilities 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). >> DR> I'd agree, but I'm not sure extending format-graph-from-roots DR> is the best way to achieve it. To be honest I'm not really DR> qualified to put forward a suggestion since I don't really DR> know enough about different kinds of graphs. DR> format-graph-from-roots et al (I'm thinking about draw-arrow, DR> draw-oval...) are purely convenience functions. I don't DR> really view them as part of CLIM even, except in as far as DR> they're in the specification and so should be implemented. Actually, the spec seems to suggest that extending the graph-drawing protocols is something that was intended. The failure to add &allow-other-keys seems like a simple oversight. "graph-type is a keyword that specifies the type of graph to draw. All CLIM implementations must support graphs of type :tree, :directed-graph (and its synonym :digraph), and :directedacyclic- graph (and its synonym :dag). graph-type defaults to :digraph when merge-duplicates is true, otherwise it defaults to :tree. Typically, different graph types will use different output record classes and layout engines to lay out the graph. However, it is permissible for all of the required graph types to use exactly the same graph layout engine." This clearly suggests an intent to allow additional graph types. It's just that additional graph types may require additional arguments to guide the layout. I don't see any downside to modifying the spec of format-graph-from-roots to allow additional keyword arguments, and I see considerable benefit. >> Another thing I'd like to see is some support for curved lines in the >> drawing layer. Franz CLIM seems to have this. DR> Franz has the 'draw-bezier-path' method I think for this. Of DR> course, this is easy to implement for Beagle (since draw-line, DR> draw-rect etc. collapse into path based Cocoa methods - Cocoa DR> is purely path based). I would guess the math isn't that hard DR> for generalised paths so I'd agree. But then, I'd say this DR> should probably be an extension too ;-) DR> Any work we would do towards an extended CLIM should be DR> thought about carefully wrt what is fundamental, and what's an DR> extension. We should provide a sensible place for extensions DR> to be placed (there are a couple of extensions in the code DR> already; personally I don't think that putting them in the DR> same file as code that's implementing specified methods is DR> correct, but I'm also a big fan of 'put them where it's DR> convenient, and tidy up later'). I find it hard to think of an ability to draw curved lines as an extension. I think it should be in the core of any modern GUI toolkit. Especially since it's going to be tempting to use curve-drawing in higher level facilities (e.g. in drawing graph edges). Adding this seems like a big win, and adding it as an extension only seems like a lose, because for portability one would have to provide a straight-line alternative to anything that involves curves. Not a happy solution, IMHO. >> 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 place >> >> Ouch. 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. DR> I was referring to one of the 'issue' points in the spec, DR> namely that some people want to remove ellipses etc. and the DR> point made there that the drawing primitives are DR> mathematically complete. Perhaps my tongue was in my cheek, DR> who knows? ;-) DR> I actually think that the windowing (sheet, medium, mirror) DR> and drawing primitive parts (regions, designs, DR> transformations) of the spec are pretty good as they DR> stand. (Pretty much?) everything else can be built on top. I DR> think that most limitations in the spec are in those other DR> bits (but then I know those parts least, so maybe that's DR> coming from my position as an observer). I tend to agree with completeness in the sense of "has enough facilities," but in the sense of "read the spec and know what an implementation will do when you use the api," I think it's deficient. DR> Not wanting to bang on about DUIM all the time, but DR> presentations etc. are not supported out of the box there; I DR> believe SM did build presentations on top though. I'm sorry, I'm missing context. What's DUIM? [...snip...]