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