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

[rpgoldman at real-time.com]

>>>>> "DR" == Duncan Rose <duncan at robotcat.demon.co.uk> writes:

    DR> On Tuesday, June 28, 2005, at 03:18  pm, Robert P. Goldman wrote:

    >>>>>>> "DR" == Duncan Rose <duncan at robotcat.demon.co.uk> writes:
    >> 
    DR> On Tuesday, June 28, 2005, at 01:37  pm, Paolo Amoroso wrote:
    >> 
    >>>> Robert Strandh <strandh at 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...]