The Weekly Juan #4: "Smalltalk,
Direct Manipulation and End User Programming"
Aaron Reichow
revaaron at bitquabit.com
Wed Nov 15 03:09:37 UTC 2006
On Nov 13, 2006, at 9:02 PM, Juan Vuletich wrote:
> Hi Andreas,
>
> Andreas Raab escribió:
>> Juan Vuletich wrote:
>>> It seems I wasn't clear (again). It is not that I don't want to
>>> discuss these items with you. What happens is that Andreas says
>>> strong and polemic opnions. I actually started to write all the
>>> things I don't agree with in that interview. But I don't think
>>> that would be polite. Perhaps if Andreas asked for other's
>>> opinions on his words...
>>
>> Sure, go for it ;-)
> For example, I don't agree at all with "Morphic is a wonderful
> architecture as far as direct manipulation is involved but it's a
> terrible architecture to build reusable systems. Morphic simply
> doesn't have any abstractions and that makes it very hard to build
> re-usable and flexible components."
First- does anyone else here agree with this view? If so, could they
elaborate it?
Once I figured out how to use Morphic (maybe in an improper way! but
it works for me!)- that is, how to code Morphic applications in a
completely programmatic way, without using any direct manipulation
and live instances hanging around, writing code I could file-out on
the dev image, file in somewhere else and have it work- I can't say I
ever felt this way about Morphic. Morphic doesn't have some kinds of
abstractions, though I'm not sure which ones that matter it doesn't
have. I guess for certains kinds of morphs (text, buttons, lists) it
would be good to have more standardization on them, more of a defined
interface, but from my experience, things seem consistent enough that
I've not been too confused.
All of my experience coding Morphic tells me just the opposite- not
only is Morphic flexible, it's a lot more flexible than anything
else. For instance, for my TaskbarMorph (on SqueakMap), I implemented
a Morph called TaskbarClockMorph. I just now, years after writing
that code, was working on a new taskbar/dock morph for a landscape-
oriented PDA (the Nokia 770). I reused that TaskbarClockMorph without
any change in code. I changed the font it used, but that was done
through a line of code in my app, not by touching the
TaskbarClockMorph's code.
I didn't do that by calling a #font: method on the TaskbarClockMorph,
but I didn't see any need to implement such a thing. Maybe that is
the kind of abstraction missing in Morphic according to some folks.
Rather, I just went to the TaskbarClockMorph instance, asked for the
text submorph and set its font. Unlike other widget sets, the new
morphs I build are composed of other morphs, and it's easy to access
those submorphs and do what I want to them. My experience on some
other platforms is just the opposite- I am stuck with what the
developer thought important enough to put it in the new widget's
API. If she thought that I woujldn't need to change the font, I was
stuck.
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.
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.
Regards,
Aaron
More information about the Squeak-dev
mailing list
|