Twiddling a twinkling Star (was: Re: Morphic question)
Lex Spoon
lex at cc.gatech.edu
Fri Jul 14 09:32:36 UTC 2000
If you want to do CS-ish things, my impression is that players and
scripting are currently not the best way to go. That may change, but I
think that's the state right now.
Anyway, in pure script-world, all your code will be represented with the
tile-based scripting system. And you can apply commands to another
specific morph by creating a tile for that other morph, and dragging the
tile over to the command. To create a tile, use the, uh, orangeish
tile, located on the left side near the bottom.
-Lex
Michael Bauers <MichaelB at firstlogic.com> wrote:
> Thanks for all of the info. I appreciate your time. I am getting the hanh
> of some of the stuff.
> I wish I had more time in the day to play with Squeak.
>
> My end intention is to try to build a simple graphical front end to some
> programs that dump out a specialized database.
> I am looking for the easiest way to build the GUI. I was hoping I could get
> away with just using scripting and players.
>
> > -----Original Message-----
> > From: Helge Horch [SMTP:Helge.Horch at munich.netsurf.de]
> > Sent: Friday, July 14, 2000 5:09 AM
> > To: squeak at cs.uiuc.edu
> > Subject: Twiddling a twinkling Star (was: Re: Morphic question)
> >
> > At 11:05 13.07.2000 -0500, Michael Bauers wrote:
> > >Well the more people keep talk, the more it sounds like the only way to
> > >access a sub morph you created in a Morphic project window, and dropped
> > on
> > >its owner (PasteUpMoprh), is through some sort of iteration??
> > >
> > >Or using that helper stuff some one else posted?
> > >
> > >I understand how to do it if I am instantiating my own Morphs, that is
> > >straightforward. But it seems as if it is not so easy if I build up
> > Morphs
> > >using the Morphic project.
> > >
> > >Wow, I thought it would be easier than all that.
> >
> > Well, I don't know if you'd consider it easy, but you may like to follow
> > this short excursion into Morphic hackery.
> >
> > First, have you all played with the "Play With Me" windows that Squeak
> > starts up with? Let's open "Play With Me - 1" and twiddle the Slider and
> > the ScrollBar for a while, and awe at how both are in sync, and how the
> > StringMorph displays the current value.
> >
> > How does it know? As far as we're concerned, they are just different
> > Morphs in a PasteUpMorph, so let's see how the slider value travels to the
> >
> > StringMorph. Bring up the halos on the world, and choose "explore
> > morph". We see it's a MVCWiWPasteUpMorph, and that it has 12 submorphs
> > (expand them). Here, there's the Slider, expand that, too.
> >
> > Ah, it has a model, a PlayWithMe1. Let's bring up a menu on that model
> > instance variable, and choose "browse class". What we see is a class that
> >
> > was generated when the Slider was added to this world. (If we look at the
> >
> > ScrollBar's model, we'll find it refers to the same model.)
> >
> > In PlayWithMe1>>slider1Value: (in the "public access" category), we
> > finally
> > see what makes the StringMorph tick:
> >
> > slider1Value: x
> > valuePrinter contents: x printString.
> > scrollBar1 value: x
> >
> > So the PlayWithMe1 instance has a reference to both the StringMorph
> > (valuePrinter) and the ScrollBar (scrollBar1), and when the Slider slides
> > to a new value, the model is notified through the method above and duly
> > sync the other two Morphs.
> >
> > The scrollBar1 instance variable was added automatically when the
> > ScrollBar
> > was added to the world, but the valuePrinter reference to the StringMorph
> > was added manually [Dan, can you confirm/remember?], as was the specific
> > implementation of #slider1Value:.
> >
> > So let's try something like this on our own.
> >
> > Open a new Morphic Project, enter it, and open a Workspace. Evaluate
> > "MorphicModel subclasses size". So what, you say.
> >
> > Now add a new StarMorph (from the Widgets category) and a new Slider (from
> >
> > the Windows category), and drop both on the world. When creating the
> > Slider, we're asked to name the part -- just accept the default
> > 'slider1'. And if we first click on the Slider, we're asked whether the
> > system "shall compile a null response for
> > MorphicModelX>>slider1Value:". Answer "yes".
> >
> > [Be careful! If you happen to cancel the second request, you encounter a
> > "self halt", the intention for which is beyond me. If you're caught in
> > that halt, drop into the debugger, and restart the offending method, then
> > you'll get a second chance to answer "yes". Works for me. <shrug>]
> >
> > If you now reevaluate "MorphicModel subclasses size", the number should
> > have increased by one. Let's now find and modify that model class to do
> > something useful.
> >
> > From the world's debug halo, choose "explore morph". See how the Slider
> > shares the model (a MorphicModel123 or so) with root (a
> > PasteUpMorph). Choose "browse class" on the model item and see what the
> > system meant by "null response": There is a #slider1 method for access,
> > and #slider1Value: that just answers self.
> >
> > What we (erm, I) now would like to do is to modify some aspect of the
> > StarMorph based on the Slider value. Pity is, the MorphicModel123 doesn't
> >
> > know about the StarMorph. So let's beat it into submission: In the class
> >
> > browser, add an instance variable "star" and a setter like this:
> >
> > star: aMorph
> > star _ aMorph
> >
> > Now for the tricky bit. We don't know about the StarMorph instance
> > either,
> > really. All we have is a fishy reference in the Explorer, in the
> > submorphs
> > list of the root PasteUpMorph. Shrug, we'll do just that: punch the
> > reference in from the Explorer. It isn't called Explorer for nothing.
> >
> > Carefully select the "root" item in the Explorer and venture to the lower
> > pane. Let's check if everything reacts as intended: In the lower pane,
> > evaluate "self submorphOfClass: StarMorph". The answer should be "a
> > StarMorph".
> >
> > Drum roll. Take a deep breath and while holding it, edit the expression
> > in
> > the lower pane to
> >
> > self model star: (self submorphOfClass: StarMorph)
> >
> > and expand the model instance variable to see it "it took". The model's
> > star instance variable should now reference the StarMorph. Also, remember
> >
> > to continue breathing now.
> >
> > We're nearly there. What's missing is that MorphicModel123>>slider1Value:
> >
> > still doesn't do something "useful". Let's try this:
> >
> > slider1Value: t1
> > star
> > ifNotNil:
> > [star color:
> > ((Color hotColdShades: 25) at: (t1 * 24) truncated + 1)]
> >
> > Accept that in the class browser for MorphicModel123 that's still around
> > somewhere. Now twiddle the slider. Instant fun.
> >
> >
> > So, to sum up the relevant bit: In a Morphic project, the corresponding
> > (auto-generated) MorphicModel subclass can coordinate and orchestrate
> > widget responses. The MorphicModel subclass is specific to the project,
> > and can be extended and modified (even renamed, IIRC) at will.
> >
> > "Is Morphic its own GUI builder?" Maybe the resident Morphic experts or
> > the PlayWithMe creators can chime in with corrections, insights and
> > explanations.
> >
> > Twinkle, twinkle, little star.
> >
> > Cheers, and thanks for listening,
> > Helge
More information about the Squeak-dev
mailing list
|