On Friday, April 29, 2005, at 08:54 AM, Paolo Amoroso wrote:
Duncan Rose duncan@robotcat.demon.co.uk writes:
something that's slow) but getting the correct part is the trick. I've read certain sections of the spec repeatedly ('geometry substrate', 'windowing substrate', parts of 'building applications' mainly), and inspected the McCLIM code in detail too in these areas and I still have no idea what the 'correct' behaviour is in many cases.
You may check the CLIM mailing list archives. They provide explanations and clarifications on many design decisions and implementation issues.
This is a useful resource (well... it's interesting) but not helpful in this case. I wasn't very clear but I was more talking about things that might relate the the back end. For example, what is a 'mirror region'? Is it the visible (presumably rectangular) area of the mirror that is visible, not accounting for occlusion? Or is it the 'physical' area of the mirror, which only makes sense when the mirror transform is taken in account? What does it mean to modify the mirror region?
I talk about this specifically because when McCLIM resizes a mirrored sheet, the size of the mirror also appears to change. This is a good thing in CLX since it appears to me that scrolling can be implemented just by informing the X server what the new offsets are, and the display is updated *by X*. This is not however so good for Beagle, since it just means I end up with a potentially huge window server object which then has to be redisplayed via the CLIM machinery. Now Cocoa has very good support for performing windowing operations that parallel CLIMs support in many ways, but it's hard to use them when dealing with a mirror that has a region of 550 x 16245 (say) and a mirror transformation that modifies y ordinates by -15800, when I could have a mirror with a region that's 550 x 445, and a noop transform.
The CLIM spec is very quiet on these kinds of issues, preferring to leave these kinds of things up to the back ends (which is a good thing) but it's very difficult to get any indication of what a 'mirror region' is INTENDED to be. I was toying with moving 'update-mirror-geometry' into the back ends, so CLX + Beagle could do this differently (and 'care-for-new-native-transformation' seems to never be invoked which is strange) but I haven't decided whether to do this or not.
It wasn't until I happened to read the glossary in the Lispworks CLIM UG that I understood that in CLIM terminology, a 'window' is just a clim-stream-pane class. Basic, maybe, but it certainly helps understanding what people are talking about sometimes ;-)
Most of this (IMHO) is definitely down to vagueness in the spec (for another example, according to the LispWorks CLIM user guide, a platform-specific fontspec can be used as a text-style (e.g. an X fontspec), and this is intimated at in the spec too, but it's not made clear). I have no idea if McCLIM supports this though (I think:
The main problem with CLIM vendors manuals is that they don't make clear what is in the spec and what is an extension.
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