'Real' zooming&panning
Joshua 'Schwa' Gargus
schwa at cc.gatech.edu
Wed Nov 5 15:30:54 UTC 2003
On Wed, Nov 05, 2003 at 08:54:21AM +0100, Andreas Raab wrote:
> > > I don't disagree with how it should look. I'm just saying
> > > that it's not the job of the Canvas to do this. If the Morph
> > > wants to draw itself differently than just scaling itself,
> > > then it's the Morph's responsibility to do so.
> >
> > Are you sure? What if I wanted to render a Morphic world as though it
> > were painted, or drawn with a pencil? One approach would certainly be
> > to have each morph take responsibility for drawing itself, perhaps
> > with methods like #drawWithPencilOn:. Another approach would be to
> > substitute in a canvas that would override the line drawing/area
> > filling methods to implement the desired style. The latter has the
> > benefit of localizing changes in one class instead of scattering them
> > across the Morph hierarchy.
>
> This is mostly a question of framework design and primarily anticipated use.
Yeah, that too ;-)
> If we would be making a drawing program where we need fine-grained control
> for the way in which objects are drawn in "stencil mode" then having a
> #drawWithPencilOn: method would be entirely reasonable (one example for this
> would be if we'd model different kinds of papers). However, given that we
> _typically_ are not interested in this in Morphic (treating most of the
> objects as "fully self-drawn" rather than composited on some simulated
> paper) your pencil example would make more sense to put into the canvas.
> [Completely OT, but I once wrote a "BluePrintCanvas" for Alan's demos which
> did draw all of the objects as blue outlines - that's pretty much what
> you're talking about].
Not OT at all; I was thinking of your BluePrintCanvas, actually. And projects
like HijackGL.
> So all in all, it really depends on how much control you want in each place.
> Both approaches can make sense depending on where exactly you need the
> fine-grained control and where you can substitute "generic behavior" that
> will work "well enough". The rule of thumb is (as always) that simple things
> should be simple and complex ones possible. So if a Morph wants to know
> whether it is drawn in a scaled environment it should absolutely be able to
> inquire on that property and draw itself differently (the same goes for your
> pencil and my blueprint example). Fortunately, all of these things _are_
> possible (though some of them require more effort than others).
>
> > Of course, other complications arise... if the size that a handle
> > is drawn is determined by the canvas, then the canvas must become
> > involved in the event handling process to decide which morph a click
> > should be handled by.
>
> Sigh. That's just one of the places in which Morphic is severely broken. The
> inability to react to changes that affect your appearance to the user is a
> real problem. If not for that, it would be trivial for the handles to resize
> themselves whenever their parent is scaled. There may be a way of doing this
> today using some crude workaround but not having this information easily
> accessible is really a flaw of Morphic.
>
> That said, NO, the canvas must NOT, NOT EVER become involved in event
> handling. The canvas is a device that supports (essentially remote) drawing
> operations and all of the state that's (during drawing) available in the
> canvas should be (trivially) accessible through the morphic hierarchy.
Agreed. I misspoke when I suggested that the canvas would have to assume some
responsibility for event handling.
The kind of thing I had in mind was picking of a morph whose shape had
been modified by the canvas (eg: WaveyBoundaryCanvas). So, a click
that would have been within the bounds of an ellipse drawn by a
regular canvas might be outside the bounds of the warped outline drawn
by the WBCanvas. If I understand you correctly, the canvas wouldn't
show up directly in the event-handling framework, but any morph would
be free to query the canvas for information necessary for proper
picking. Is this correct?
Joshua
>
> Cheers,
> - Andreas
>
More information about the Squeak-dev
mailing list
|