On Sat, 2008-06-14 at 21:37 +0200, Bert Freudenberg wrote:
> On 14.06.2008, at 19:03, Ross Boylan wrote:
>
> > On Sat, 2008-06-14 at 13:43 +0200, Bert Freudenberg wrote:
> > ....
> >>
> >> The path methods are a beautifully simple and useful, but they are
> >> also a particularly bad example of Morphic programming.
> > Does this mean that they could be done properly in Morphic? In other
> > words, is the problem here with Morphic, or with this particular
> > approach?
> >
> > Or maybe it's just very difficult to do properly in Morphic?
>
> It's more complicated - e.g., both definePath and followPath are
> single methods now, done properly it would require at least a few
> methods - setup, event handlers, stepping, cleanup ... the control
> flow would be sprinkled across a few methods. This is typical of
> almost any event-based UI, you typically would have a mouse-down
> handler that sets up a few things, a mouse-move handler to collect the
> path, and a mouse-up handler to gather the result. And these handlers
> have to be enabled only while the path is recorded.
>
> > I also have a more general question: if I'm not doing fancy animations
> > or 3D effects, are there any particular benefits or drawbacks of using
> > Tweak?
>
> Tweak has nothing to do with 3D, it is purely 2D. But for example, the
> definePath or followPath methods could be implemented in a single
> method with local control flow which is really nice to program.
>
> - Bert -
I think this is relevant even for very vanilla tasks. I just re-read
the original Tweak memo
http://tweakproject.org/ABOUT/FAQ/OriginalTweakMemo/ and now see it in a
new light.
I recently made an application that (simplifying) I originally was going
to do like this
mainLoop
myList do: [:anItem |
self updateDisplayWith: anItem.
self waitForUserSelection.
self actOnSelection: aSelection.
].
Then I realized that "self waitForUserSelection" wasn't going to work.
I ended up with something like this:
setup
myIndex := 1.
self launchGUI. "establishes a call back to #userSelection:"
self updateDisplay.
userSelection: aSelection
self actOnSelection: aSelection.
myIndex < myList size ifTrue: [
myIndex := myIndex + 1.
self updateDisplay.
].
If I understand correctly, Tweak would be more amenable to my original
plans. I think Seaside also does something similar. Am I on the right
track?
A complication is that what I've rendered as "waitForUserSelection" is
covering up several distinct events: a click on a list, a couple button
presses, or an entry in a text field. In the "Morphic" approach I can
set each of these to a different callback. In the Tweak approach, do I
need to decode the event I get from waitForUserSelection? The original
tweak memo has "button waitUntil: #click", but I have several possible
events.
Ross
>
> > I was intrigued by some statements that Tweak has a clearer
> > separation of model and the graphical/interactive part (View/
> > Controller
> > in MVC). I definitely have separate model classes, and have found
> > Morphic a bit awkward for that reason. It does have pluggable Morphs,
> > though.
> >
> > Ross
> >> You may notice how the entire World stops while you define a path
> >> (have a clock morph running to see this). Also it uses Sensor
> >> directly, and calls displayWorld. Both big no-nos in proper Morphic
> >> programs. The followPath method even does the actual animation in a
> >> background thread. Really Bad Things can happen if you do that.
> >>
> >> Tweak did set out to allow this kind of programming (because it is so
> >> convenient), and it succeeded in that.
> >>
> >> For the original question - if you want the actual cover flow effect
> >> you need a 3D renderer. You could use Croquet and OpenGL for that,
> >> but
> >> it might be overkill. The Balloon3D render should be enough for this
> >> simple type of animating.
> >>
> >> If you can live with a pseudo-3D effect (like the carousel seen on
> >> the
> >> amazon.com frontpage) you can use simple 2D morphic animation of
> >> course. In that effect, the covers always remain parallel to the
> >> screen but only move position in a 3D circle so that they become
> >> smaller in the back and larger in the front, and of course are sorted
> >> back-to-front ...
> >>
> >> In fact, that is so simple I couldn't resist to make an etoy version,
> >> 4 lines of code :)
> >>
> >> Uploaded as
> >>
> >> http://wiki.squeak.org/squeak/uploads/Carousel.pr
> >>
> >> - Bert -
>
>
> _______________________________________________
> Beginners mailing list
> Beginners@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
_______________________________________________
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
