Morphic 3 presentation at Smalltalks 2007

stephane ducasse stephane.ducasse at
Thu Jan 24 07:50:28 UTC 2008

Now what would be a nice step in that direction would be to have a  
small tutorial
on the UiBuilder that already exists in Squeak ToolBuilder.
Once brian started but I could never put my hand on it to read it/ 
improve it/ build on it.


On Jan 24, 2008, at 3:32 AM, Laurence Rozier wrote:

> On Jan 23, 2008 8:09 PM, Juan Vuletich <juan at> wrote:
> Hi Jason,
> Jason Johnson wrote:
> > On Jan 23, 2008 12:42 AM, Juan Vuletich <juan at> wrote:
> >
> >
> > You're the one who said Morphic isn't for the "average  
> programmer". :)
> >
> Well, I said "I'm not doing Morphic 3 to suit the average programmer
> needs". That doesn't mean that Morphic isn't for the average  
> programmer.
> It means that my objectives are not finding out what are the needs of
> the average programmer. I really don't know what they are. And I don't
> care too much.
> To be clear I fully respect your free time and choices so if none of  
> this matters to you it's fine by me. I just think that when you say  
> you are working on Morphic 3.0 with the implication that it is the  
> future of the Squeak GUI you're inviting input.
> There are a lot of "average programmers" who are very bright and  
> motivated people that happen to have other full time professions.  
> What they want are a set of rock-solid components they can use out  
> of the box to code basic interfaces - the list of Widgets/V  
> components, though 17 years old isn't far off the mark. The GUI  
> builder in Widgets/V left a lot to be desired - which is how/why it  
> evolved into WindowBuilder, but the components opened a new world of  
> possibilities for "average programmers". None of the current Squeak  
> GUIs - Morphic, E-Toys or Tweak provide these rock-solid components  
> out of the box, but it seems like Morphic 3.0 could as a matter of  
> course. I like many of the ideas in Morphic 3.0 and don't see having  
> a set of practical, core components as being in conflict with them.  
> In fact, I think they are complimentary in many respects - they  
> provide excellent test suites and broaden the base of testers which  
> always helps any GUI.
> Cheers,
> Laurence
> >
> >> 
> Morphic.html .
> >>
> >
> > Best link I've seen yet.  Thanks, I'm going through it.
> >
> Thanks!
> >
> >> Then pay more attention.
> >>
> >
> > Oh I do.  I read every message I see about Morphic on the list,  
> trying
> > to see what it's "kill feature" is.
> >
> >
> Quoted alone, my phrase sounds rude. I apologize. I meant that Squeak
> itself is a great place to study and learn. I don't think the point is
> about a "kill feature". I think it is about flexibility and openness.
> I've never used C#, or anything but Smalltalk in the last 10 years,  
> but
> I don't believe something like EnvelopeEditorMorph could be done  
> with so
> little and simple code. Anyway, I might be wrong. If C# is so good,  
> then
> why not use it? If its GUI framework and tools are that good, why not
> port them to Squeak?
> > I looked at that class and I saw a Morph containing a piano, a  
> view on
> > a musical scale and a few menus. If I get time I may take a crack at
> > it in the C# or Dolphin environment because it seemed pretty  
> straight
> > forward (and one always learns why it isn't in implementation :).
> >
> It also has actual envelopes you can grab with the mouse to modify the
> sound. If you can do something like that in C# or Dolphin, with as
> little code as in Morphic, please tell me, and let me see the code.
> >
> >> Well, I helped write an application that way in 1997 using  
> VisualAge
> >> Smalltalk (now VA Smalltalk). Also VisualWorks and Visual Smalltalk
> >> supported or still support that way of programming. In my  
> experience,
> >> and that of many others, code is much better at tackling real  
> complex
> >> applications and at building a mainteinable system.
> >>
> >
> > Well, is that because it is the best way to do it, or because the
> > tools don't help us constructing the interfaces enough?
> I don't know, but if you have hope on "visual programming" I suggest
> using Parts in VisualWorks, or the VisualBuilder in VisualAge, write  
> an
> application (without code, only arrows connecting objects), maintain  
> it
> (i.e. modify it and keep it working) and find out for yourself if a
> better tool could make that way of programming useful.
> > Of course
> > building applications via code must be supported, but in a system
> > built in itself like Smalltalk, of course it will be.  I watched the
> > Self video and they seemed to be building some pretty interesting  
> and
> > complicated things in a largely graphical way.
> >
> >
> >> I believe the whole
> >> "visual programming" idea failed for professional developers.
> >>
> >
> > That's a rather bold statement.  It depends again on how you're  
> going
> > to define "professional developers" but if you define them as people
> > who get paid to program then I suspect that the vast majority of all
> > developers writing native GUIs are doing so in a mostly graphical
> > manner and have been for decades.
> >
> Decades? The first visual programming tools commercially available are
> about 15 years old. And most people build guis with gui builders, but
> almost nobody use visual programming tools. May be we are not speaking
> about the same, visual programming means defining the application
> behavior without code (not only the GUI, the model too). I say this  
> idea
> failed, because (almost) nobody uses it, and tool vendors don't sell  
> it
> as the future anymore.
> >
> >
> >> I don't think why would you think that. I really believe you need  
> more
> >> reading and studying Squeak.
> >>
> >
> > Mainly because having read the tutorials and papers on Self and
> > Morphic from Sun's research web site, it seemed that Morphic  
> gained a
> > lot of power from the object instance modification capabilities.
> > Since Smalltalk is a class based system you lose much of that ( e.g.
> > adding a method ad-hoc to a morph you're working on).  The way one  
> has
> > to do it in Smalltalk is by programatically generating classes,  
> which
> > I dislike.  In Etoys, one programs at a higher level so it doesn't
> > matter so much how things are implemented at the lower levels you
> > don't see, but at the Smalltalk level it doesn't strike me as very
> > elegant.
> >
> I see. However, I don't agree. I think programming in Smalltalk by
> defining classes is both powerful and elegant.
> > And I'm sure you're right that I do need to read more.  Squeak is
> > quite vast with a great deal to learn.
> >
> >
> :)
> Cheers,
> Juan Vuletich

More information about the Squeak-dev mailing list