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

[Duncan Rose]

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