[mcclim-devel] possible buglet in highlighting shapes

[Duncan Rose]

On Friday, April 29, 2005, at 08:54 AM, Paolo Amoroso wrote:

> Duncan Rose <duncan at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>