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

[Duncan Rose]

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).
>

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 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.

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
>