The problem is that window is a special morph and it is not meant to
be embedded in another morph. It would be much better if for example
the canvas would be in a more regular morph (maybe a panel or even
in the scroller) and this container to raise the announcement.
I see. I will investigate on this.
I hope to come back to you shortly.
On 15 Jan 2010, at 16:29, Alexandre Bergel wrote:
> After an interaction from the user (e.g., node dragging, node
> selection), the announcement MOContentChanged is emitted by
> When I scroll an MOCanvas (e.g., as it occurs when in an easel or a
> view renderer the picture is larger than the visible window), when
> a window containing a MOCanvas is dragged, moved, resize, the event
> WindowAnnouncement is emitted.
> I made a dedicated method, called
> MOViewRenderer>>setDefaultHandlerForWindow: systemWindow that
> register relevant announcement handlers for a number of
> announcement, including node dragging, key down, MOContentChanged
> and WindowAnnouncement.
> The only thing to do to have a proper update should be to use
> NB: When writing this email, I realized that the handler of
> WindowAnnouncement was set in a different location than
> MOContentChanged, which is odd. I produced a new version of
> Mondrian that reflect this.
> NB2: now that I thinking about this, maybe MORoot>>updateWindow is
> not an ideal name since the root is not aware of the window in
> which it is (indirectly) embedded.
> On 15 Jan 2010, at 11:44, Tudor Girba wrote:
>> Hi Alex,
>> I am trying to debug the problem of embedding Mondrian in Glamour
>> and I have a question.
>> Why exactly does Mondrian need to know the window to update? Why
>> is it not enough to just know the Canvas morph?
>> "Problem solving efficiency grows with the abstractness level of
>> problem understanding."
>> Moose-dev mailing list
> Alexandre Bergel http://www.bergel.eu
> Moose-dev mailing list
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list