The Weekly Juan #4: "Smalltalk, Direct Manipulation and End User Programming"

On Tue, 14 Nov 2006 21:09:37 -0600, Aaron Reichow <[hidden email]>
wrote:

> Along these lines, I shall be sharing some screencasts soon of  
> building simple Morphic apps. I did a simple tutorial over VNC with  
> bmp on #squeak the other evening and it went really well.

I have done a bunch of GUIs in Morphic, and I find it quite nice. Like
Aaron, I build them completely programmatically.

Some simple screens are displayed here:

http://www.huv.com/uSeeker/smalltalk/screenshots.html

A much more complex editor window, with a direct manipulation scrollable
zoomable draggable graphics pane is here:

http://www.huv.com/roboMagellan/MissionEditor.jpg

I'm pretty happy with what I can do with Morphic... Of course, there are
things that could be better (like the speed), but all in all it is one of
the most flexible GUI architectures I have ever used.

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

  Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
           http://www.huv.com

>From: Andreas Raab <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Viewing in Morphic (was: Re: The Weekly Juan #4: "Smalltalk,
>Direct Manipulation and End User   Programming")
>Date: Mon, 13 Nov 2006 20:58:59 -0800
>
<snip>
>
>So, I guess I have to correct myself, Morphic does indeed support viewing
>via step-polling (but I still wouldn't call that a viewing architecture ;-)
>
>Cheers,
>   - Andreas
>

I don't know much about how morphic does it's work, but I definitaley think
polling is bad. :)

I think how Dolphin does it is really nice.  For those who don't know, in
Dolphin they use MVP (Model View Presenter).  The basic difference in the
concept is: the View is responsible for displaying itself, as well as
responding to user events.  The Presenter is the glue between the Model and
the View.  It can recieve events from the View as high level or low level as
it want.  I.e. it can get an event like "user has selected 5 rows and did
(via right click) the 'make bold' command", or it can go as low as asking
for every key press and/or mouse move.

Every model has to be derived from the Model class, and you do have to take
care that if one of your Model methods updates another part of the model
(e.g. the view requests to add a transaction, but this causes the model to
update it's balance), you have to send an event explicity.

As far as the normal model changes, you don't have to send events yourself.  
In the presenter you just create an "Aspect" for each field you are going to
manage.  This part is kind of like Magritte, but you specify the Aspect
(e.g. SelectBoxAspect for enum type values) in the Presenter instead of the
Model.  I believe the Aspect class does a "#send: anEvent on: aModel", to
handle all other views getting updated.  And in this way, you have to send
the event yourself if you call those methods directly, but no polling has to
be done.

This is how I think it works anyway (I didn't know enough about smalltalk at
the time to even check).  I hope it doesn't do polling! :)

_________________________________________________________________
Get today's hot entertainment gossip  
http://movies.msn.com/movies/hotgossip?icid=T002MSN03A07001

Aaron Reichow wrote:
> What am I missing? To me, Morphic is about nothing if not flexible and
> reusable. A morph is a morph is a morph.  That said, I do think it can
> be hard to wrap one's head around the first time- but the payoff is
> worth the time invested.

agreed

Stef

On 11/15/06, Aaron Reichow <[hidden email]> wrote: I would have implemented that font: method, because it abstracts
away the details of the internal structure of the clock morph, and
this tends to pay off in the long run. I also agree that Morphic is
flexible and easy to work with. I usually have a model and use an
observer-type of pattern to update the morphs. When I first saw
Morphic, I was very suspicious of the lack of a model - morphs
seemed to be all UI-objects! Then I realized that this is sometimes
simple and useful, and that it is easy to do your own morph-model
architecture.

Best regards, Micke

Hi Bert,

Thanks for the explanation.

Cheers,
Juan Vuletich

Bert Freudenberg escribió:

Jecel Assumpcao Jr <[hidden email]> writes:
> Someone mentioned that the language had been changed from Smalltalk, but
> it is impossible to tell from the information on the company site
> (though you can register to download it and see for yourself). A good
> starting point for information about this system is:
>
> http://www.smalltalk.org/versions/OOVM.html


More info here:

  http://wiki.cs.uiuc.edu/Resilient/Issues

This claims, and I had heard, that its blocks cannot be returned or
stored in the heap.  IMHO that is such a major limitation that it is
hardly Smalltalk any longer.


-Lex

>A much more complex editor window, with a direct manipulation
scrollable
>zoomable draggable graphics pane is here:
>
>http://www.huv.com/roboMagellan/MissionEditor.jpg
>

Hi John, is your MissionEditor code available ?  It seems
interesting to build “mission” or “route” for a GPS. I get a
Garmin GPS.

Hi Lex,

>
>  http://wiki.cs.uiuc.edu/Resilient/Issues
>
> This claims, and I had heard, that its blocks cannot be returned or
> stored in the heap.  IMHO that is such a major limitation that it is
> hardly Smalltalk any longer.
>

That limitation was there from the begining. Lars Bak explained in ESUG 2003
that it made the implementation of the Smalltalk interpreter much simpler. I
specially liked the idea because it would make concrete type inference
possible on those systems. And one of his students followed that path

http://blogs.sun.com/ahe/resource/peter-ahe-thesis.pdf

In my opinion, without blocks Smalltalk would taste very differently. But I
must agree with Marcel Weiher when he says that Smalltalk is not a pure OO
language. Because of the blocks it can be characterized as hybrid, mixing
elements from OO and FP.

http://www.metaobject.com/papers/HOM-Presentation.pdf

Cheers,
Francisco

On Thu, 16 Nov 2006 17:20:35 -0500, Asselin Raymond
<[hidden email]> wrote:

> Hi John, is your MissionEditor code available ?  It seems
> interesting to build “mission” or “route” for a GPS. I get a
> Garmin GPS.

You know, I'm pretty sure I answered this already...

But here goes again...

No, it is part of my autonomous controller code. I could separate it out,
but the model behind the UI is actually the autonomous controller itself,
so it would be a bunch of work.

I'll have a look at the code and see how easy it would be to pull that part
out.

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

  Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
           http://www.huv.com

"Francisco Garau" <[hidden email]> writes:

I would agree it makes type inference more precise, as does any
language change that narrows down the flexibility of runtime dispatch.
I would argue with the "possible" part, though.  You and I have both
written Smalltalk type inferencers that are not foiled by the presence
of blocks.

Anyway, I had the impression the main motivation was to make the
Resilient run fast, and that type inference benefits were secondary.
After all, Resilient targets less powerful devices.


> In my opinion, without blocks Smalltalk would taste very differently. But I
> must agree with Marcel Weiher when he says that Smalltalk is not a pure OO
> language. Because of the blocks it can be characterized as hybrid, mixing
> elements from OO and FP.

Well, it's pure in the sense that it has all the OO fundamentals,
*and* all the values act like proper objects.  So let's say it's not
"merely" OO instead of it's not "pure" OO.  It takes all of OO, plus
parts of FP.

Anyway, all this said, it sounds like Resilient's blocks are at least
sufficient for the collection methods like do: and select: to work.
Those, IMHO, are some of the most useful applications of blocks in
Smalltalk, the ones I'd miss the most if blocks were removed entirely.


-Lex