[mcclim-devel] incremental redisplay and with-first-quadrant-coordinates
Hi, The attached file defines two application frames which differ essentially only in their use of with-first-quadrant-coordinates. In the one (BAR) without with-first-quadrant-coordinates, incremental redisplay behaves as I expect; in the other (FOO) with, strange things happen. I believe this is connected with output record moving; if I change state-matches-stream-p in incremental-redisplay to query both X and Y coordinates of the stream cursor, the display of both applications is as I expect. Cheers, Christophe
Hello, I think what you are seeing is a bug in McCLIM which is either due to a bad specification, a bad implementation of the specification, or both. Getting the different transformations (user-, medium-, sheet-, device-) right is hard, and I am sure getting them right in the presence of output recording is even harder. -- 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. ---------------------------------------------------------------------
I've started to take a look at this. Christophe pointed out that the code that checks the stream cursor is only checking the x coordinate; apparently a bug, but this change was specifically made during Gilbert's rewrite of the compute-difference-set code, so I don't think it's right to check both x and y without understanding what he's doing there. Gilbert? :) Tim On Jun 27, 2005, at 3:10 PM, Robert Strandh wrote:
Hello,
I think what you are seeing is a bug in McCLIM which is either due to a bad specification, a bad implementation of the specification, or both. Getting the different transformations (user-, medium-, sheet-, device-) right is hard, and I am sure getting them right in the presence of output recording is even harder. -- 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. --------------------------------------------------------------------- _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Timothy Moore <moore@bricoworks.com> writes:
I've started to take a look at this. Christophe pointed out that the code that checks the stream cursor is only checking the x coordinate; apparently a bug, but this change was specifically made during Gilbert's rewrite of the compute-difference-set code, so I don't think it's right to check both x and y without understanding what he's doing there. Gilbert? :)
I don't think that's the bug -- without removing the y-coordinate check, no output record is ever /moved/ even if it's unchanged apart from its stream-position. (I think actually that the x-coordinate shouldn't be checked either: that way arbitrary translations of output-records would be possible. I don't know why that wasn't implemented at the time...) Cheers, Christophe
On Monday, June 27, 2005, at 02:10 pm, Robert Strandh wrote:
Hello,
I think what you are seeing is a bug in McCLIM which is either due to a bad specification, a bad implementation of the specification, or both. Getting the different transformations (user-, medium-, sheet-, device-) right is hard, and I am sure getting them right in the presence of output recording is even harder.
Isn't the medium transformation the same thing as the user transformation? Or rather, shouldn't they be the same? -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. --------------------------------------------------------------------- _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Duncan Rose writes:
On Monday, June 27, 2005, at 02:10 pm, Robert Strandh wrote:
Hello,
I think what you are seeing is a bug in McCLIM which is either due to a bad specification, a bad implementation of the specification, or both. Getting the different transformations (user-, medium-, sheet-, device-) right is hard, and I am sure getting them right in the presence of output recording is even harder.
Isn't the medium transformation the same thing as the user transformation? Or rather, shouldn't they be the same?
Maybe. I can't remember. -- 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. ---------------------------------------------------------------------
Actually, I think it is time to give McCLIM a major overhaul, though I am not convinced anybody has the time. Such an overhaul would start by correcting and supplementing the specification where it is wrong and/or incomplete. We might call the document obtained this way the CLIM 2.2 specification. It would be much more precise than the CLIM 2.0 specification, and we would make sure as much as possible that it does not have any contradictions.
From the CLIM 2.2 specification, chunks of the code base could be refactored, checked, and selectively rewritten.
All of this, of course, requires more manpower, which we do not have. -- 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. ---------------------------------------------------------------------
On Monday, June 27, 2005, at 02:30 pm, Robert Strandh wrote:
Actually, I think it is time to give McCLIM a major overhaul, though I am not convinced anybody has the time.
I agree with this; at the very least, I think it needs a thorough review, and notes taken where the implementation disagrees with, or extends, the spec. I don't know how many annotations there are on the annotatable spec but I'm sure plenty of things didn't make it onto that document (it was out of order for a while).
Such an overhaul would start by correcting and supplementing the specification where it is wrong and/or incomplete. We might call the document obtained this way the CLIM 2.2 specification. It would be much more precise than the CLIM 2.0 specification, and we would make sure as much as possible that it does not have any contradictions.
Don't both Lispworks and Franz already have 'CLIM 2.2'? Neither of which agree by the way (either with each other, or in several places, with the spec, for those methods (the vast majority) that are listed in the spec). Do we need to take the vendor CLIMs into account at all? I'm currently putting together a document comparing the methods in the spec, the different user guides, and as implemented in McCLIM but it's slow going. Perhaps it will be useful one day. -Duncan
From the CLIM 2.2 specification, chunks of the code base could be refactored, checked, and selectively rewritten.
All of this, of course, requires more manpower, which we do not have.
-- 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. --------------------------------------------------------------------- _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Duncan Rose writes:
Don't both Lispworks and Franz already have 'CLIM 2.2'?
Oh, OK, 2.3 then :-)
Do we need to take the vendor CLIMs into account at all?
I seriously doubt it. As far as the vendors are concerned, CLIM is dead.
I'm currently putting together a document comparing the methods in the spec, the different user guides, and as implemented in McCLIM but it's slow going. Perhaps it will be useful one day.
Definitely! -- 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. ---------------------------------------------------------------------
Robert Strandh <strandh@labri.fr> writes:
Duncan Rose writes: [...]
Do we need to take the vendor CLIMs into account at all?
I seriously doubt it. As far as the vendors are concerned, CLIM is dead.
What about users of commercial CLIM implementations? On the other hand, if those users are sufficiently interested in CLIM, they should probably put some pressure on their vendors. Robert, Duncan (and others): are you suggesting that McCLIM should become a new CLIM standard[*]? Paolo [*] For appropriate--and sufficiently fuzzy--values of "standard". -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
On Tuesday, June 28, 2005, at 01:37 pm, Paolo Amoroso wrote:
Robert Strandh <strandh@labri.fr> writes:
Duncan Rose writes: [...]
Do we need to take the vendor CLIMs into account at all?
I seriously doubt it. As far as the vendors are concerned, CLIM is dead.
What about users of commercial CLIM implementations? On the other hand, if those users are sufficiently interested in CLIM, they should probably put some pressure on their vendors.
Robert, Duncan (and others): are you suggesting that McCLIM should become a new CLIM standard[*]?
Personally I'd like to see McCLIM in a *state* where it could be used as a base for a new standard. An actual new standard is perhaps less important to me. OTOH a couple of extra chapters in the existing spec and some of the confusing or contradictory stuff being rewritten would be very cool. I think in general the ideas behind CLIM stand up pretty well in the face of 'modern' windowing systems. The main lack as I see it in CLIM is support for i18n, particularly bidi text layout and multi-key input sequences. Perhaps more thought needs to be put into embedding frames too (DUIM is at a point where windows components can be embedded in DUIM frames; I don't see why CLIM couldn't be somewhere similar). (In fact Apple (or NeXT) seem to have copied silica wholesale as the windowing parts of Cocoa.) All the rest (transparent window backgrounds? Arbitrarily shaped windows?) seem like eye candy to me. I care about them not ;-) (but would still like to see them supported. They may be already, if enough hoops are jumped through. Certainly I don't see any of them being *against* the specification). Whilst the CLIM presentation paradigm isn't common I really don't see that it prevents anybody writing a CLIM app that fits in nicely with those other windowing systems (we might need to do something on selections. But even this I feel isn't a large divergence from the spec) Perhaps I'm missing something fundamental regarding the facilities offered by other systems, I just can't think of much that needs adding to CLIM. I think we'll just need an additional chapter or two rather than a new spec. - this is the benefit of starting with a 'mathematically complete' specification in the first place -Duncan
Paolo
[*] For appropriate--and sufficiently fuzzy--values of "standard". -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
"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). Another thing I'd like to see is some support for curved lines in the drawing layer. Franz CLIM seems to have this. 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. Best, R
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).
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
"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...]
rpgoldman@real-time.com writes:
I'm sorry, I'm missing context. What's DUIM?
If I understand correctly, it is an improved, CLIM-like system for Dylan implemented by Scott McKay while working at Xanalys. Their Dylan product was called Functional Developer. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
On Tuesday, June 28, 2005, at 07:36 pm, Paolo Amoroso wrote:
rpgoldman@real-time.com writes:
I'm sorry, I'm missing context. What's DUIM?
If I understand correctly, it is an improved, CLIM-like system for Dylan implemented by Scott McKay while working at Xanalys. Their Dylan product was called Functional Developer.
Yes. The source for Functional Developer is available under the LGPL from the Gwydion Dylan site (http://www.gwydiondylan.org/), including DUIM. It's worth a look I think. -Duncan
Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Von: Duncan Rose <duncan@robotcat.demon.co.uk> Datum: Tue, 28 Jun 2005 20:45:58 +0100 An: Paolo Amoroso <amoroso@mclink.it> Cc: McCLIM <mcclim-devel@common-lisp.net> Betreff: Re: [mcclim-devel] incremental redisplay and with-first-quadrant-coordinates
On Tuesday, June 28, 2005, at 07:36 pm, Paolo Amoroso wrote:
rpgoldman@real-time.com writes:
I'm sorry, I'm missing context. What's DUIM?
If I understand correctly, it is an improved, CLIM-like system for Dylan implemented by Scott McKay while working at Xanalys. Their Dylan product was called Functional Developer.
Yes. The source for Functional Developer is available under the LGPL from the Gwydion Dylan site (http://www.gwydiondylan.org/), including DUIM. It's worth a look I think.
At one point Scott McKay was interested in designing a CL-based port of DUIM. DUIM btw. lacks a few things from CLIM.
-Duncan
Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
_______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
rpgoldman@real-time.com writes:
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.
You do have to think about consequences to output recording, specifically testing whether two regions overlap, etc. -- 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. ---------------------------------------------------------------------
"RS" == Robert Strandh <strandh@labri.fr> writes:
RS> rpgoldman@real-time.com writes: >> 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. RS> You do have to think about consequences to output recording, RS> specifically testing whether two regions overlap, etc. I didn't mean to suggest that I thought adding something like Bezier curves would be easy (or that I would be competent to do it)! Just that because (1) it's at such a low level of the abstraction hierarchy and (2) it would be hard to provide alternatives in portable code, it should not be an extension, but rather a core component. R
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"?
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.
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.
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? -- 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. ---------------------------------------------------------------------
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. ---------------------------------------------------------------------
Duncan Rose writes:
It also sounds like it's already written and just needs rolling into the McCLIM code base proper?
Not MY code at least. I was very unhappy with the result. Both with respect to rendering quality and to performance.
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').
I don't mind calling it implementation note, but in a document to be used by someone using CLIM for application programming, it should have the correct wording. -- 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. ---------------------------------------------------------------------
To: Duncan Rose <duncan@robotcat.demon.co.uk> Date: Wed, 29 Jun 2005 14:07:38 +0200 From: Robert Strandh
I don't mind calling it implementation note, but in a document to be used by someone using CLIM for application programming, it should have the correct wording.
The spec is not meant to be used by application programmers, under normal circumstances. A "programming guide" is for that purpose. The absence of a programmer's guide is not the faultof the spec. Mike McDonald mikemac@mikemac.com
Mike McDonald writes:
The spec is not meant to be used by application programmers, under normal circumstances. A "programming guide" is for that purpose. The absence of a programmer's guide is not the faultof the spec.
I see you point, but the layered design of CLIM makes it hard to distinguish between an advanced application programmer and a CLIM implementor. That is probably also why CLIM user manuals tend to turn into the spec after just a few chapters. Take care, -- 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. ---------------------------------------------------------------------
Robert Strandh <strandh@labri.fr> writes:
I see you point, but the layered design of CLIM makes it hard to distinguish between an advanced application programmer and a CLIM implementor. That is probably also why CLIM user manuals tend to turn into the spec after just a few chapters.
Or maybe because Lisp vendor resources for producing additional CLIM documentation or instructional material have always been limited. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
There was always supposed to be an additional low-level documentation of CLIM. It never happened. The first versions of CLIM (1.0) also were never as extensible and never had some of these layers (Silica). Much of the extensibility and the UI adaption have been added for CLIM 2.0. Xerox had worked on ist own version of the CLIM implementation and developed the Silica layer. Silica then was added for the joint CLIM 2.0 implementation. UI adaption also was added with CLIM 2.0. If you look at the comparable implementation of DW (Dynamic Windows), the father of CLIM, it was better documented, had a better look&feel, and had also more features in several areas. DW's documentation is about twice as large. CLIM was supposed to be a simplification, implemented with CLOS (instead of New Flavors) and it should have had better performance. Though my feeling is that DW was faster and had less bugs. What does that mean for McCLIM? There is only little documentation, tutorials etc.. So it needs to be written over time. Idea: integrate some wiki mode into Climacs and write the documentation there.
Von: Paolo Amoroso <amoroso@mclink.it> Organisation: Paolo Amoroso - Milano, ITALY Datum: Thu, 30 Jun 2005 11:30:21 +0200 An: McCLIM <mcclim-devel@common-lisp.net> Betreff: Re: [mcclim-devel] incremental redisplay and with-first-quadrant-coordinates
Robert Strandh <strandh@labri.fr> writes:
I see you point, but the layered design of CLIM makes it hard to distinguish between an advanced application programmer and a CLIM implementor. That is probably also why CLIM user manuals tend to turn into the spec after just a few chapters.
Or maybe because Lisp vendor resources for producing additional CLIM documentation or instructional material have always been limited.
Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
Paolo Amoroso writes:
Robert Strandh <strandh@labri.fr> writes:
Or maybe because Lisp vendor resources for producing additional CLIM documentation or instructional material have always been limited.
I considered that possibility, but then imagined what a complete user manual would look like, and it would necessarily contain most, if not all, of the spec. -- 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. ---------------------------------------------------------------------
Does anyone else have encountered the following problem while trying to start the clim examples with (clim-demo::demodemo) the error I got is: error opening #P"/tmp/.X11-unix/X0": File exists [Condition of type SB-INT:SIMPLE-FILE-ERROR] Restarts: 0: [ABORT] Abort handling SLIME request. 1: [ABORT] Exit debugger, returning to top level. Of course the file is there I'm running X11 and I suppose that is good thing. So what does good for is this error message? Regards Friedrich
Paolo Amoroso writes:
What about users of commercial CLIM implementations? On the other hand, if those users are sufficiently interested in CLIM, they should probably put some pressure on their vendors.
If I understand the situation correctly, the only CLIM applications that clients of commercial Lisp systems use are legacy applications that are not developed further. As long as CLIM is maintained intact and available on new releases of the Lisp implementation, the clients are happy.
Robert, Duncan (and others): are you suggesting that McCLIM should become a new CLIM standard[*]?
Not exactly. I am suggesting that the developers around McCLIM are probably the best suited to making the standard evolve, so I am suggesting that we work on clarifying and fixing the document in ways that would alter it as little as possible, and then that we make McCLIM a correct implementation of that fixed-up standard. -- 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. ---------------------------------------------------------------------
Von: Robert Strandh <strandh@labri.fr> Datum: Tue, 28 Jun 2005 13:22:17 +0200 An: Duncan Rose <duncan@robotcat.demon.co.uk> Cc: McCLIM <mcclim-devel@common-lisp.net> Betreff: Re: [mcclim-devel] incremental redisplay and with-first-quadrant-coordinates
Duncan Rose writes:
Don't both Lispworks and Franz already have 'CLIM 2.2'?
Oh, OK, 2.3 then :-)
Do we need to take the vendor CLIMs into account at all?
I seriously doubt it. As far as the vendors are concerned, CLIM is dead.
Almost. Some applications are still using CLIM. The last change that happened was that some people bought CLIM source rights (Alice Hartley of Digitool is one of those). Consequently Digitool offers a CLIM version that is also available with full sources. Both Franz and LispWorks are fixing bugs sometimes, but are not investing into new work with CLIM. Franz now ports ist toolkit from Windows to Linux and LispWorks does only CAPI anyway.
I'm currently putting together a document comparing the methods in the spec, the different user guides, and as implemented in McCLIM but it's slow going. Perhaps it will be useful one day.
Definitely!
-- 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. --------------------------------------------------------------------- _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
--- Rainer Joswig <joswig@lisp.de> wrote:
Almost. Some applications are still using CLIM.
The last change that happened was that some people bought CLIM source rights (Alice Hartley of Digitool is one of those). Consequently Digitool offers a CLIM version that is also available with full sources.
Both Franz and LispWorks are fixing bugs sometimes, but are not investing into new work with CLIM. Franz now ports ist toolkit from Windows to Linux and LispWorks does only CAPI anyway.
Perhaps I shouldn't suggest this, but a thought occurs... If vendors are no longer developing CLIM, or even supporting it except as a legacy standard, perhaps one or more of them might consider releasing their code to McCLIM? Since McCLIM is LGPL, there wouldn't seem to be much of an issue with them including it in their future releases, and they would get the benefit of any additional work McCLIM does to improve things. Also, they would get the additional benefit of being able, with little to no additional effort, to run programs that get developed with McCLIM on their own lisps without having to worry about their own CLIM's compatibility. (Granted the latter won't be an issue unless customers demand it, but in case they do...) Plus, even if CLIM is no longer the "modern" choice for lisp GUIs, it's availablity as a robust, open source system may help spur lisp development into a more mainstream mode. Certainly lack of readily usable graphics toolkits is one of the things most frequently cited as a limitation of lisp. If McCLIM can change that perception, wouldn't that benefit everybody, commercial and free lisp vendors alike? Particularly if McCLIM works seamlessly across platforms - Java might see a real (and truly open source!) competitor. They would seem to have at least a few things to gain and virtually nothing to lose, given CLIM isn't where things are happening for their commercial customers graphically. Does this make sense to anybody else or am I missing something obvious? Cheers, CY ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com
To: Rainer Joswig <joswig@lisp.de>, To: Robert Strandh <strandh@labri.fr>, To: Duncan Rose <duncan@robotcat.demon.co.uk> Date: Tue, 28 Jun 2005 09:08:27 -0700 (PDT) From: C Y
If vendors are no longer developing CLIM, or even supporting it except as a legacy standard, perhaps one or more of them might consider releasing their code to McCLIM?
I'm not sure they can release the code. It all depends on the original license terms. They code is copyrighted by over a half dozen companies, most of which don't exist any more. [Just because the companies don't exist, doesn't mean that someone doesn't own the rights. Most likely a lawyer!!] I tried to work with Franz years ago to release a copy of their version but I never even got a response to my enquiry. Mike McDonald mikemac@mikemac.com
To: Robert Strandh <strandh@labri.fr>, To: Duncan Rose <duncan@robotcat.demon.co.uk> Date: Tue, 28 Jun 2005 14:43:45 +0200 From: Rainer Joswig
The last change that happened was that some people bought CLIM source rights (Alice Hartley of Digitool is one of those). Consequently Digitool offers a CLIM version that is also available with full sources.
Bought the rights from whom? Mike McDonald mikemac@mikemac.com
Von: Mike McDonald <mikemac@mikemac.com> Datum: Tue, 28 Jun 2005 20:37:01 -0700 An: Rainer Joswig <joswig@lisp.de> Cc: Robert Strandh <strandh@labri.fr>, Duncan Rose <duncan@robotcat.demon.co.uk>, McCLIM <mcclim-devel@common-lisp.net> Betreff: Re: [mcclim-devel] incremental redisplay and with-first-quadrant-coordinates
To: Robert Strandh <strandh@labri.fr>, To: Duncan Rose <duncan@robotcat.demon.co.uk> Date: Tue, 28 Jun 2005 14:43:45 +0200 From: Rainer Joswig
The last change that happened was that some people bought CLIM source rights (Alice Hartley of Digitool is one of those). Consequently Digitool offers a CLIM version that is also available with full sources.
I don't know (haven't asked). Maybe Alice Hartley can answer that. I guess there are also some MCL customer involved who have applications in MCL's CLIM.
Bought the rights from whom?
Mike McDonald mikemac@mikemac.com
Robert Strandh wrote:
Duncan Rose writes:
Do we need to take the vendor CLIMs into account at all?
I seriously doubt it. As far as the vendors are concerned, CLIM is dead.
Interesting thread this. I'd love to comment on this remark and a few others in this thread, but I'm afraid I won't have time for this today or tomorrow. I'm too busy with CLIM support for Franz customers at the moment... -- Arthur Lemmens
--- Arthur Lemmens <alemmens@xs4all.nl> wrote:
Robert Strandh wrote:
Duncan Rose writes:
Do we need to take the vendor CLIMs into account at all?
I seriously doubt it. As far as the vendors are concerned, CLIM is dead.
Interesting thread this. I'd love to comment on this remark and a few others in this thread, but I'm afraid I won't have time for this today or tomorrow. I'm too busy with CLIM support for Franz customers at the moment...
Oh dear. Well, I guess that makes my suggestion rather moot - if CLIM is still an active tool Franz will probably want to retain it's competitive edge over McCLIM :-). Cheers, CY __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail
Arthur Lemmens writes:
Interesting thread this. I'd love to comment on this remark and a few others in this thread, but I'm afraid I won't have time for this today or tomorrow. I'm too busy with CLIM support for Franz customers at the moment...
I guess you did mention that last time we met, though I don't think we had time to discuss any details. -- 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. ---------------------------------------------------------------------
Arthur Lemmens <alemmens@xs4all.nl> writes:
Interesting thread this. I'd love to comment on this remark and a few others in this thread, but I'm afraid I won't have time for this today or tomorrow. I'm too busy with CLIM support for Franz customers at the moment...
I am personally very interested in knowing your and/or Franz's views on CLIM here, in the CLIM mailing list, or any other Lisp forum you prefer. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
participants (1)
-
Arthur Lemmens -
C Y -
Christophe Rhodes -
Duncan Rose -
Friedrich Dominicus -
Mike McDonald -
Paolo Amoroso -
Rainer Joswig -
Robert P. Goldman -
Robert Strandh -
rpgoldman＠real-time.com -
Timothy Moore