[plt-scheme] move-to in refresh

Matthew,

Thank you for the explaination. I'm pretty convinced I can't do what I want 
using refresh in that case. This is what I'm currently attempting to do:

My aligned-pasteboards need to know the sizes of the snips they contain in 
order to know how to align them in a geometry managed layout. Snips within a 
pasteboard do not get sizes until the pasteboard is displayed. This means 
if snips are inserted into an aligned-pasteboard before they it is displayed 
they will be layed out as if their sizes were all zero. What needs to happen 
is when an aligned-pasteboard is finally displayed something needs to poke 
it and say "hey the snips in you have real sizes now, recalculate the layout 
before we draw you to the screen"

When the pasteboard is displayed, there are two methods which are called, 
refresh and on-paint. I figured I'd give it a shot by overriding refresh to 
realign the pasteboard, but in order to realign the pasteboard I need to 
call move-to.

This brings me to my question, is there a possbilility that pasteboards 
could get a new method that would be called when the pasteboard is displayed 
and its snips sizes obtained via get-snip-location become valid? If not I'll 
seek some other way around this problem.

-mike

On Thu, Aug 05, 2004 at 03:07:41PM -0600, Matthew Flatt wrote:
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
> At Thu, 5 Aug 2004 13:31:59 -0400, "Mike T. Machenry" wrote:
> > Is it not allowed to call move-to from within refresh?
> 
> I think that's the `move-to' called will have to be disallowed. It's no
> immediately obvious how to fix the contracts (and docs), though, to
> formalize the prohibition.
> 
> The problem is that `refresh' is called when the owning editor is
> redrawing itself. The `move-to' for the owned editor triggers a resize,
> which gets propagated to the owning editor --- but the owning editor
> can't accept the resize, because it's busy redrawing.
> 
> When the owning editor is a text%, it effectively realizes that it
> can't handle the resize and just gives up. A pasteboard%, in contrast,
> doesn't notice and ends up waiting on a lock that is held during
> redraws (i.e., it deadlocks).
> 
> In general, an editor should not change its shape during a `refresh'
> call.
> 
> Matthew
>