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

Hi Folks,

The Weekly Juan #4 is out at www.jvuletich.org . Today I talk about
various Smalltalk user interfaces and how Morphic 3.0 relates with them.

Hope you like it. Any comment is welcome.

Cheers,
Juan Vuletich

Juan Vuletich wrote on Mon, 06 Nov 2006 21:02:14 -0300
> The Weekly Juan #4 is out at www.jvuletich.org . Today I talk about
> various Smalltalk user interfaces and how Morphic 3.0 relates with them.
>
> Hope you like it. Any comment is welcome.

Very good!

The only thing I would add about MVC is that it makes good use of the
fact that humans have a single locus of attention (chapter 2 of Jef
Raskin's "The Humane Interface" goes into detail about this). So there
is one active object on the screen while all the others are frozen.
Using the pointer position as a proxy for the locus, the Controllers
collaborate to quickly switch which one of them is active. In a similar
way, only the top View can be updated but as soon as the user is
interested in a different View it comes to the top and is refreshed. I
consider this to be the visual equivalent of the "block variables are
really method temporaries" hack in that most people don't notice any
problems. Bill Atkinson from Apple was so convinced he had seen
partially obscured windows being updated in the famous PARC Smalltalk-80
demo that he worked long and hard to come up with a way to reproduce
this for the Lisa and Mac (what he called "region algebra").

While this is fine for business style applications, it was not a good
option for artificial worlds like ARK, Morphic and EToys. Here we
replace the collaborating Controllers with something more similar with
preemptive scheduling, with all objects being constantly polled with
#step messages. Obviously there is a huge price to pay in terms of CPU
cycles.

I did find this comment about Self a bit strange:

"Most programmers believe the Smalltalk-80 environment is more
productive, and the software built is easier to maintain."

Other than John Maloney's interview in SqueakNews, what other
programmers have expressed this view? While I can't be sure what John
meant, I think he was happy to be using the system browser again where
you get a whole view of the system (like a "map" page in a web site). In
Self there are lots of places where objects you might be interested in
could be hiding besides the "globals" object. As more and more projects
started to live outside the official imagine in Squeak (which happened
long after that interview) this has become a problem here as well,
though the introduction of the SqueakMap did a lot to tame it.

I am typing this in Linux, though I find QNX and Plan 9 far better
technically. The reason is the community (and, as a consequence, the
available software). In the same way I am typing this in Squeak
(Celeste) instead of Self merely because of the community. If people who
have experience using both Self and Squeak feel the latter is "more
productive, and the software built is easier to maintain" I would very
much like to hear about it.

-- Jecel

Hi Jecel,

Thank you for your feedback. (more below).

Jecel Assumpcao Jr escribió:
> Very good!
>  
Thank you. Wow! I added this text to the article. I hope you don't mind. If you do,
I'll remove it.
> While this is fine for business style applications, it was not a good
> option for artificial worlds like ARK, Morphic and EToys. Here we
> replace the collaborating Controllers with something more similar with
> preemptive scheduling, with all objects being constantly polled with
> #step messages. Obviously there is a huge price to pay in terms of CPU
> cycles.
>  
Of course.
> I did find this comment about Self a bit strange:
>
> "Most programmers believe the Smalltalk-80 environment is more
> productive, and the software built is easier to maintain."
>  
My idea was to be objective. Clearly that phrase was completely
subjective. Thanks for pointing it out. I removed it. Well, I don't know many Self programmers. In addition to John's opinion
(crucial for me), I have a good friend who worked a couple of years on
an application written in NewtonScript. He felt the same as John: the
browser is a great way to organize code. Besides, code based development
(i.e. not relying on the assembly of objects in a certain image) eases
team work and version tracking.

> I am typing this in Linux, though I find QNX and Plan 9 far better
> technically. The reason is the community (and, as a consequence, the
> available software). In the same way I am typing this in Squeak
> (Celeste) instead of Self merely because of the community. If people who
> have experience using both Self and Squeak feel the latter is "more
> productive, and the software built is easier to maintain" I would very
> much like to hear about it.
>
> -- Jecel
Now I have a third opinion: yours. You don't agree with them, so today I
would say "Some programmers believe...". Anyway, as I said above, I took
it off. This article is not about my opinion.

Thank you so much.
Juan Vuletich

Juan Vuletich wrote on Wed, 08 Nov 2006 21:55:22 -0300
> Wow! I added this text to the article. I hope you don't mind. If you do,
> I'll remove it.

Please free feel to use it - that was the purpose of me posting this
here. Speaking of the motives behind the various Squeak GUIs, Offray
Vladimir Luna Cárdenas mentioned today on #squeak this interview with
Andreas Raab about Tweak that is very worth reading:

http://squeak.pbwiki.com/interview

> My idea was to be objective. Clearly that phrase was completely
> subjective. Thanks for pointing it out. I removed it.

You can be subjective in your own pages if you like. I was just very
curious since my own Neo Smalltalk design is even more extreme than Self
and it would be nice to know what problems people have with this kind of
system.

> Well, I don't know many Self programmers. In addition to John's opinion
> (crucial for me), I have a good friend who worked a couple of years on
> an application written in NewtonScript.

Note that NewtonScript is a cross-development system, which makes it
feel very different from a native development environment independently
of any other of its features. Just try something like PocketSmalltalk or
Resilient to see what I meant.

> He felt the same as John: the
> browser is a great way to organize code.

I agree. But to repeat what I said before, as we move to a more modular
and open system we will lose Squeak's "show me everything" features. The
system browser will only show you want you happen to have loaded in this
particular image, not something that is on SqueakMap; sending
#allInstances doesn't let you see stuff that might live in some project
you haven't loaded yet and so on. This future can't be avoided and it
would be a good idea for our tools to adapt to this new reality.

> Besides, code based development
> (i.e. not relying on the assembly of objects in a certain image) eases
> team work and version tracking.

Here I must strongly disagree. Back in 1997 I had two trainees working
for me and doing some simple Self programming. Given that you can open
more than one window on the same Self world and the cross computer
features of the X Window system, they would sit at two different
workstations on the same room (but with voice chat they could have been
very far away with the same effect) and engaged in very intense pair
programming (a bit different from how the Agile folks do it). Unless you
had seen it yourself it is hard for you imagine how much fun this was
and how productive they were (not counting crashes - the system should
have been a bit more robust). All this using live objects.

Sure, this is a total pain if you depend on CVS. But this is like saying
Mac text files are totally useless just because you have to edit them
with Notepad.exe. Don't confuse the limitations of your current tools
with inherent limitations of a certain style of development.

> Now I have a third opinion: yours. You don't agree with them, so today I
> would say "Some programmers believe...". Anyway, as I said above, I took
> it off. This article is not about my opinion.

I am always willing to change my mind, and so like to know why people
don't agree with me. Sometimes they know something that I don't, though
often it is the other way around (somebody who thinks static typing is
better than dynamic, for example, but has only programmed in C++ and
Java). See the comment about image based environments at the end of
http://en.wikipedia.org/wiki/Self_computer_language to see what I mean.

Anyway this is all just a very tiny detail and your article was very
good even with that comment.

-- Jecel

Jecel Assumpcao Jr <[hidden email]> writes:
> Juan Vuletich wrote on Wed, 08 Nov 2006 21:55:22 -0300
> > Besides, code based development
> > (i.e. not relying on the assembly of objects in a certain image) eases
> > team work and version tracking.
>
> Here I must strongly disagree. [...] Unless you
> had seen it yourself it is hard for you imagine how much fun this was
> and how productive they were....

The two are not incompatible.  You can use exported code as the
authoritative version of the code, while using an object-rich image to
actually edit that code.

In fact, this is the *normal* way to develop in Smalltalk.  You can
always start in a fresh image if you want.  You simply load all the
code off the disk or out of your version control system.

-Lex

Hi Jecel,

Jecel Assumpcao Jr escribió:
> Please free feel to use it - that was the purpose of me posting this
> here.
Thanks.
> Speaking of the motives behind the various Squeak GUIs, Offray
> Vladimir Luna Cárdenas mentioned today on #squeak this interview with
> Andreas Raab about Tweak that is very worth reading:
>
> http://squeak.pbwiki.com/interview
>  
I don't agree with many of the ideas expressed there. But I don't want
to start a useless discussion. I'll just continue with Morphic ideas.
It's good to have options.
>> My idea was to be objective. Clearly that phrase was completely
>> subjective. Thanks for pointing it out. I removed it.
>>    
>
> You can be subjective in your own pages if you like. I was just very
> curious since my own Neo Smalltalk design is even more extreme than Self
> and it would be nice to know what problems people have with this kind of
> system.
>  
Sure. But this time I didn't want to. I don't like mixing facts with
opinions without making clear the difference. BTW, I'd like to know more
about Neo Smalltalk! Is it available for Windows or Linux? Yes. You're right. That's true too. But today, I work on a single Smalltalk environment,
and that's ok.
  What you describe is really coll. But I used the wrong words. "Team
work" is not specific enough. I meant "merging the work of different
people into a single consistent construct". I also think that code
(thinking more on change sets or an Envy like system than CVS) helps
tracking versions and comparing them. I don't know of any such tools for
Self, but as you say, this doesn't mean they can't be done. I looked there. Sad.
I'd love to have some real experience with Self. But unfortunately I
don't see that happening any time soon.
> Anyway this is all just a very tiny detail and your article was very
> good even with that comment.
>
> -- Jecel
Thank you.
Juan Vuletich

Lex Spoon wrote on 10 Nov 2006 12:18:41 -0800
Right. My programming style, however, involves creating instances and
not just code and in that case collaboration means something like
Nebraska instead of Monticello. Given the goals of the Croquet project I
imagine that I am not alone in wanting to use computers this way.

-- Jecel

Juan Vuletich wrote on Sat, 11 Nov 2006 00:29:04 -0300
> > http://squeak.pbwiki.com/interview
> >  
> I don't agree with many of the ideas expressed there. But I don't want
> to start a useless discussion. I'll just continue with Morphic ideas.
> It's good to have options.

We can never have a perfect GUI, so options are certainly a very good
thing. I am not sure discussing things we don't agree with is useless,
however.

> Sure. But this time I didn't want to. I don't like mixing facts with
> opinions without making clear the difference. BTW, I'd like to know more
> about Neo Smalltalk! Is it available for Windows or Linux?

I am developing the software and hardware together, so in theory it will
only be available on my machine (but since it will be open source
somebody could port it). I am using a simulator written in Squeak to
debug this, The version on my site is from January but I'll post a new
one as soon as I have something that is more usable. So it will run on
PCs, but not in real time.

> > [the future is open systems]
> >
> That's true too. But today, I work on a single Smalltalk environment,
> and that's ok.

You work on a single environment until you want to share with someone
using a different image. We are having more and more problems in this
regard, though I agree we can live with them a while longer.

> > [collaborating trainees using Self]
> >  
> What you describe is really coll. But I used the wrong words. "Team
> work" is not specific enough. I meant "merging the work of different
> people into a single consistent construct". I also think that code
> (thinking more on change sets or an Envy like system than CVS) helps
> tracking versions and comparing them. I don't know of any such tools for
> Self, but as you say, this doesn't mean they can't be done.

Since they were using the same image, their work was always instantly
merged. But this is sometimes a problem and not a solution, so the Self
group created the "Us" language which allowed multiple simultaneous
viewpoints (similar to the old PIE system for Smalltalk-80, but a bit
more dynamic).

> I'd love to have some real experience with Self. But unfortunately I
> don't see that happening any time soon.

Unfortunately Sun has just killed the project a second time. At least
Macs are easier to find the Sparc machines.

-- Jecel

Hi Jecel,

> Note that NewtonScript is a cross-development system, which makes it
> feel very different from a native development environment independently
> of any other of its features. Just try something like PocketSmalltalk or
> Resilient to see what I meant.

Is the Resilient Smalltalk available somewhere?

Thanks,
Francisco

Jecel Assumpcao Jr escribió: 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...
It is enough for me to say that Morphic is great for building
abstractions, allows separation of view and model (but does not enforce
it), and I don't see any need for a different architecture. I work on a 10 person team, with VSE. We do as Lex said in other message
in this thread. The stuff each programmer publishes is change sets (code).
Cheers,
Juan

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 ;-)

> It is enough for me to say that Morphic is great for building
> abstractions, allows separation of view and model (but does not enforce
> it), and I don't see any need for a different architecture.

I'm curious how you come to this conclusion. In particular considering
that Morphic has no theory of viewing (the Pluggable* classes for
example were added as an afterthought to support apps written for MVC
and have nothing to do with what I would consider a "true Morphic app").

Cheers,
   - Andreas

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."

"Because MVC is a "viewing architecture"... Tweak ... provides a viewing
architecture similar to MVC." I don't agree with this either. In Tweak,
a player knows its primary costume. In MVC, one of the key ideas is that
a view knows its model, but a mode knows nothing about the views on it.
I believe the viewing architecture to be quite different.

WRT method annotations for event handlers, it seems as if the receiver
of the message for some object was always the object triggering the
event. Usually it is not. It could be an owning morph, or the model(if
the event is from the gui), or the view (if the event is from the
model). This is also related to the model not knowing about the view in MVC. ScorePlayerMorph and EnvelopeEditorMorph are good examples of views on a
model, in the classic MVC idea of the view knowing about the model, and
the model not knowing about the view. I don't see the need for a "theory
of viewing". It is enough with separating the view and model
responsibilities, and triggering events, just as in MVC.

Cheers,
Juan Vuletich

[Changing the subject since this part seems to be mostly about viewing]

Juan Vuletich wrote:
> 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."

Which part do you disagree with? That it's a wonderful architecture for
direct manipulation? That it's a terrible architecture for building
reusable systems? That it doesn't have abstractions?

> "Because MVC is a "viewing architecture"... Tweak ... provides a viewing
> architecture similar to MVC." I don't agree with this either. In Tweak,
> a player knows its primary costume. In MVC, one of the key ideas is that
> a view knows its model, but a mode knows nothing about the views on it.
> I believe the viewing architecture to be quite different.

You're actually only looking at a part of viewing in Tweak - namely that
of graphical models which indeed know their primary views. This is not
generally true - all that is required for viewing in Tweak is that an
object #signal: the occurrence of an event that a view can observe
(which is very much like MVC's change/update mechanism except that it
executes asynchronously by default and is supported and used all the way
top to bottom in Tweak). And many Tweak objects act as views on numerous
other objects (indeed, part of the implementation of Tweak depends on
objects "viewing themselves").

For *grapical* models (players) it is indeed true that they know their
primary view (the costume) but this is mostly to optimize management of
some state (which is held exclusively in the costume). I actually
debated this for quite a while initially and went for it due to the
space savings, but I may (have to) reconsider it in the context of
Croquet simply because there may be no notion of a "primary" view for a
(replicated) model under a (non-replicated) viewing environment.

> WRT method annotations for event handlers, it seems as if the receiver
> of the message for some object was always the object triggering the
> event. Usually it is not. It could be an owning morph, or the model(if
> the event is from the gui), or the view (if the event is from the
> model). This is also related to the model not knowing about the view in
> MVC.

I presume that by "the receiver of the message for some object was
always the object triggering the event" you mean that the signaler and
the handler of the event are the same (if not, please clarify). If
that's what you mean then you are right, usually they are not the same.
This is why you have <on: eventName in: signaler> annotations (and the
common <on: eventName> is effectively shorthand for <on: eventName in:
self>).

Part of the goal for these annotation is that for many applications it's
nice to be able to "centralize control" in a single place. In other
words, I often prefer a style that uses:

onFireInMyButton
    "MyButton has been fired. Carry out some action."
    <on: fire in: myButton>
    target doButtonAction.

to one that uses, e.g.,

    button on: #mouseDown send: #doButtonAction to: target.

The latter version certainly has its uses but I find the former much
more accessible in terms of looking at a class and how it defines the
relationship between the entities it deals with (in particular in a
Tweak browser where event methods have icons so that you can immediately
see which of them are event responses).

Another major advantage is that when I need to add/change/remove one of
these events I don't have to poke around all over the places to find
where the button is initialized and change other people's code - I can
write a clean new method, state the relationship right there and then
and get the result. Plus, renaming and changing events doesn't require
me to execute manual code (the system takes care of transferring the
triggers), nor does it require me to manually change event relationship
if the button ever changes (again, Tweak transfers the event responses
automatically when you change a field). [there are numerous other
advantages that I won't list here because this is getting excessive already]

And just for completeness, there is of course a way to do the
programmatic equivalent of the latter via:

   target startScript: #doButtonAction when: {button. #fire}.

So the bottom line is, you're right, often the signaler and the handler
of an event aren't the same and Tweak supports that common use case too.
And I would claim that it supports this use case better than Morphic
ever could.

> ScorePlayerMorph and EnvelopeEditorMorph are good examples of views on a
> model, in the classic MVC idea of the view knowing about the model, and
> the model not knowing about the view. I don't see the need for a "theory
> of viewing". It is enough with separating the view and model
> responsibilities, and triggering events, just as in MVC.

Interesting. For two reasons really. First, I wouldn't even consider
these to be "morphs" but rather what I would call "application shells".
By which I mean there is nothing intrinsically graphical about the two,
nor even anything interactive - neither of the two chosen examples
implements drawing or event handling (mouse or keyboard) which given the
definition of a Morph as:

[Morph classComment]
        A Morph (from the Greek "shape" or "form") is an interactive graphical
object.

strikes me as non-Morphic as it gets (given that the two defining
properties of being graphical and being interactive aren't met).

But besides, you do realize that both of the examples you are mentioning
are polling in their step methods for any changes in the model, right? I
think one could consider this a form of viewing but I don't consider
step-polling to be an actual viewing architecture because it gets very
excessive pretty quickly. Case in point: PianoRollScoreMorph. It polls,
too, and when it detects a change in its model it recreates all these
morphs from scratch (besides the criticism implied here it's actually
quite impressive how well this works). However, given current Morphic
usages step-polling seems to be the prevalent method of determining
changes in Morphic.

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

Hi Andreas,

Andreas Raab escribió: I agree that "That it's a wonderful architecture for direct
manipulation". I don't agree with "That it's a terrible architecture for
building reusable systems". I don't agree with "makes it very hard to
build re-usable and flexible components." I see no need for something called a "graphical model" and not just a
model as in MVC, etc. yes.
> If that's what you mean then you are right, usually they are not the
> same. This is why you have <on: eventName in: signaler> annotations
> (and the common <on: eventName> is effectively shorthand for <on:
> eventName in: self>).
>
I missed that. How do you reference signaler? I mean, each instance of
the handler could want events from a particular signaler, perhaps one
that still doesn't exist when you compile the method! Perhaps it is an
instance variable of the handler? If you prefer it, that's ok. I find both to be quite graphical, and quite interactive. I don't know
what you mean here. That's not a property of the graphic frameworks but of the models being
observed. And those models are not part of the framework. Of course the
models could trigger events. But these examples show that not even that
is needed. So, I don't see the need for a "theory of viewing". You see,
any model can work. That's the fundamental idea of the separation of
View and Model as in MVC. The model is outside of the framework. It can
be any object.
>
> 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
Of course you know you can also use events. I guess you're just kidding.
And I agree with you, Morphic doesn't specify a "viewing architecture".
And there's no need for one.

Cheers,
Juan

(separating this from the Morphic discussion)

On Nov 14, 2006, at 11:22 , Juan Vuletich wrote:

Yes, it is like an instance variable (actually a field, which is used  
exactly like an instance variable but generates change events on  
assignment).

When compiling, only existing instances are updated. But when  
creating a new instance, the field will be nil, so no event handlers  
will be registered for that event, yet. But a second event handler is  
installed that handles a change event for that field - it will  
register the actual event handler as soon as you assign to the field.

This is an example for what Andreas meant with "indeed, part of the  
implementation of Tweak depends on objects 'viewing themselves'".  
This is totally non-graphical, it takes the model/view separation  
idea down to the system core itself.

- Bert -

Francisco Garau wrote on Tue, 14 Nov 2006 00:40:10 -0000
> Is the Resilient Smalltalk available somewhere?

It was available for free trial download back in 2004 here:

http://www.oovm.com/download.php

They were bought by Esmertec in July of 2004 which has a product called
"OSVM", which I suppose is either the same thing or closely related to
OOVM:

> http://www.esmertec.com/solutions/M2M/OSVM/FeaturesandComponents.shtml

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

-- Jecel

Il giorno mar, 14/11/2006 alle 14.39 -0300, Jecel Assumpcao Jr ha
scritto:
> Someone mentioned that the language had been changed from Smalltalk, but
> it is impossible to tell from the information on the company site

This blog post (and other on the same site) has some info:

http://blog.quenta.org/2006/04/why-neptune.html

        Giovanni

On Nov 10, 2006, at 2:08 PM, Jecel Assumpcao Jr wrote:

That's true to some extent. While most of my NewtonScript programming  
was done on the Newton itself using NewtDevEnv, an on-board IDE, I do  
have some experience using the cross-dev tools that run on a host Mac/
PC.  I seem to recall that in addition to the stale code and GUI  
layout you were working on, you could also be connected to the Newton  
and its live object ecosystem- it lacked the ultimate power even  
Smalltalk-80 has, but it was closer to ån image-based Smalltalk way  
of doing things than writing C.  You had access to live objects, etc  
if you were connected to the Newton when doing development.  If you  
added a VNC server for the Newton and a tool like ViewFrame, you got  
even closer- it is cross development, but nothing like you have with  
Pocket Smalltalk, which is 'dead' rather than 'alive' like your usual  
Smalltalk.

But how far along do you want to travel down this path?  If I were  
building a Smalltalk-ish environment for another dynamic language-  
REBOL, some Lisp, Python, whatever- my code browser wouldn't show me  
the classes of everything and everything ever written for it.  Don't  
get me wrong- it would be cool to have a way to do this for certain  
situations, but in the end, I want to see what I got.  If I need some
functionality, I go find a package, load it, and then look at it.

Am I misremembering, but doesn't VisualWorks have something sort of  
like you're describing? That is, you have what is in your image, you  
have stuff on a server somewhere, but you also have a bunch of cached/
downloaded packages in a goodies folder.  I have a vague recollection  
that VW will show you the stuff in that goodies folder, but greyed  
out- you can right click and load it, and then it's real. I might be  
hallucinating this, but if it isn't a possibility, this might be a  
possible model for getting what you're talking about.

About the #allInstances comment- do I really want to see all the  
instances of some class across all published projects on SqueakMap? I  
mean, there are cases when this would be awsome, especially if it  
were transparent- but that seems to be more the domain of a peer to  
peer Magma system, something entered in intentionally, not the  
default behavior when I'm looking around at the code and objects in  
my system.  I think a massively distributed system would be  
incredibly cool- but I don't think it makes sense just yet.

I can second this, actually. I did some work like this using Squeak.  
We had a machine which was running Squeak and Nebraska but with no  
local keyboard/mouse/display. We both connected to it and worked.  We  
usually were on at different times and generally waited til the other  
was off, but we did do simultaneous coding a handful of times- and it  
worked pretty well.

This is hard to wrap your head around if you've not used a system  
like Morphic, in Self or Smalltalk.  I don't think most other GUI  
toolkits have the possibility for multiple hands. It's a shame,  
because this sort of forward thinking in Morphic seems to buy you a  
lot of cool stuff for relatively little cost.

> Sure, this is a total pain if you depend on CVS. But this is like  
> saying
> Mac text files are totally useless just because you have to edit them
> with Notepad.exe. Don't confuse the limitations of your current tools
> with inherent limitations of a certain style of development.

Well said. I might have to copy this for future reference- I often am  
trying to say precisely this to people new to Squeak in #squeak or in  
real life.

Regards,
Aaron

On Nov 10, 2006, at 2:18 PM, Lex Spoon wrote:

Indeed.  You don't even need anything fancy like Monticello.  The way  
I generally develop in Squeak is to:

1. Have an agreed design among the parties involved.
2. Keep stuff well sorted in class and method categories.
3. Use changesets.
4. Change what came with the image as little as you can.  But when  
these changes are made, distribute them seperately.
5. For everything else, I just file out the categories.

This might sound downright medieval to some, it's not failed me yet,  
even in projects where there are a few people involved.

Regards,
Aaron

On Nov 13, 2006, at 9:02 PM, Juan Vuletich wrote:

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