Morphic

I was doing a lot of playing with Morphic this week at ESUG in Barcelona.  Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.

I think it's amazingly powerful and universally misunderstood.  Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role.  For me, there are two use cases:
1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible
2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.

Morphic seems ideal for group #1.  I think the key questions are:
* if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?
* what would it take (if possible) to get there from the current implementation?

Two issues I've noticed:
1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph.
2. I'm not clear whether the hooks for modifying behavior are
        a. available in all the right places
        b. working
        c. widely understood

I'm forming an informal panel to discuss this.  I've reached out to Morphic's creators and some original users.

A quick example of my (seemingly common) experience:
For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors.  So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code.  At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph.

I tried (one of these felt very satisfying):
* Morph>>on:send:to:, which sounded good, but never got called
* intercepting Morph>>processEvent:using: (which I was told was not a good idea)
* (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input).
* subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.

Sean

  On 9/17/2010 12:29 PM, DeNigris Sean wrote:
> I was doing a lot of playing with Morphic this week at ESUG in Barcelona.  Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
>
> I think it's amazingly powerful and universally misunderstood.  Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role.  For me, there are two use cases:
> 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible
> 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
I don't know all the answers. But I do believe there is a tremendous
amount of unsubstantiated claims about "native" UIs and there value or
importance. First and foremost the biggest offenders of non-native UIs
or rather look-and-feel for apps on almost any OS is the OS vendor
themselves. Yet, there users seem to do fine.

Come on, is iTunes a native look-and-feel for an OS? Or Safari, two apps
from the creator of oh so elegant and beautiful. I don't really think
so. I don't even think they are particularly attractive or intuitive. Or
Quicktime. Or Internet Explorer. Or Windows Media. etc...  I really
can't go into any further detail as I am not currently using a Mac and I
use as little MS software as I possibly can on my Windows OS machine.

How about old Visual Basic or Hypercard apps?

How about AIM, Yahoo Messenger, or whatever current cool tool is out
there. Are they following any of the mantras tossed around by the we
want native crowd? Not really.

How about educational software and games. Both very common with lots of
use. People seem to manage fine.

Do I think Squeak/Pharo have to have arrived at their best UI. No, not
at all. But I definitely do not believe "native" is better. And "native"
never automatically means intuitive. It may be or not depending on the
app. And non-native does not mean un-intuitive and poor quality.

I do think we can do better. I do like the idea of having multiple OS
windows available to the app developer. But I don't like being dependent
on anybody else to fix a bug or port their UI or widgets to the next
great OS. Heck I'm ready for Pharo 2.x/3.x to become my next OS. :)

Whatever we do. I believe it is very important for us to maintain our
control over our destiny. For me, wx, qt or whatever just simply reduces
us to the same playing field as Python, Ruby, etc. I really believe we
can be better. It is one of the reasons I use Squeak/Pharo/Smalltalk.

To me the more we can do in Smalltalk the better. I say that fully
understanding outside requirements. I am currently in the process of
building an application in Pharo which requires the use of a Windows COM
dll. This is a business requirement. Unfortunately, that is something I
can not do in Pharo right now. Yes I  know one of you wizard may be able
to do something with Alien, FFI, or whatever. But it is something not
currently accessible to people who only use the Smalltalk side of
things. It is very easy to do in Python, which is what I used to write
an intermediate application which communicates between the COM dll and
my Pharo app.

So I do understand, certain real world use case requirements for
interfacing outside elements. I just don't believe the UI is really one,
especially when counter examples are so incredibly abundant and are some
of the biggest apps in use anywhere and often written by the OS vendor.

I am not an implementer of any of these things, only a user. But these
are some things I observe. YMMV, IMHO, all the standard disclaimers.  
:)  :)  :)

Jimmie

Inline...

On Sep 17, 2010, at 10:29 AM, DeNigris Sean <[hidden email]> wrote:

> * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?

I might go with prototypal inheritance ahahahaha. (Sorry! Couldn't resist! :-) )

> Sean

DeNigris Sean wrote:
> I was doing a lot of playing with Morphic this week at ESUG in Barcelona.  Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
>
> I think it's amazingly powerful and universally misunderstood.  

I agree.

> Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role.  For me, there are two use cases:
> 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible
> 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
>
> Morphic seems ideal for group #1.  I think the key questions are:
> * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?
>  

I _am_ implementing Morphic today. In fact I'm doing it twice at the
same time:
- Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler
and smaller than in Squeak, although the basic ideas are the same.
- Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and
http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep
redesign. The main ideas are to make it a ZUI, independent of pixel
resolution, and use new, higher quality techniques for rendering.

> * what would it take (if possible) to get there from the current implementation?
>  

The path I'm walking is: Phase 1 - Remove all non-essential stuff,
simplify as much as possible. Phase 2 - Redesign from there. Morphic in
Cuis is phase 1. Morphic 3 is phase 2.

> Two issues I've noticed:
> 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph.
> 2. I'm not clear whether the hooks for modifying behavior are
> a. available in all the right places
> b. working
> c. widely understood
>
> I'm forming an informal panel to discuss this.  I've reached out to Morphic's creators and some original users.
>  

I'd like to be part of that. Are you setting up a mail list?

Your morph should answer true to #handlesMouseDown: and implement
#mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples
of this in the image already.

You'd really try Cuis. You'll find it much easier to understand and extend.

Cheers,
Juan Vuletich

CONTENTS DELETED

Yes
and I would like to have a kind of MVP model.

Stef

On Sep 18, 2010, at 9:15 AM, Hilaire Fernandes wrote:

On 18.09.2010, at 09:50, Giuseppe Luigi Punzi Ruiz wrote:

> I will start to learn morphic now.
>
> I was one of the ofenders of morphic look and feel,and right now,looking to 4.1,I love it.
>
> The only thing I miss,is more than 1 host window. Something like VW,where you can have Browser,Transcript,and so on,on different windows.There are some discussion about this in the past,and some implementation (ffenestri?) But not any conclusion (is not possible?).

It's possible. It has been done, e.g. using Tweak. You just need to Do It.

Some people want it, but not badly enough to actually put in work. The infrastructure is all there by now (well, except for the unix VM, which has the primitives stubbed out, and iPhone/iPad/Android where "native windows" are considered seriously last millennium).

If all you want is easier switching between browser windows, add the window switcher (can't remember what the package is called, it's like the Windows taskbar).

- Bert -

On 9/18/10, Giuseppe Luigi Punzi Ruiz <[hidden email]> wrote:
> I will start to learn morphic now.
>
> I was one of the ofenders of morphic look and feel,and right now,looking to
> 4.1,I love it.

Giuseppe,

To learn Morphic I recommend to download Cuis and to start going
through the class comments of Morphic. There are very few classes (the
names  of _all_ copied in below).

Juan' s downsized and cleaned-up version of Morphic is completely
functional. What you learn there may be applied to the Morphic of
Squeak 4.2alpha trunk and Pharo as well.

You will learn a lot just by browsing two or three hours through the
source code of Cuis.

Start reading with 'Morphic-Kernel', class 'Morph', look as well at
the instance variables. They have documentation. A lot of obstacles
for understanding the code have been removed.

A suggestion: as you go through it - would it be possible to update
class comments in the Squeak Morphic? I assume a lot is missing there.
Minimal thing would be just to copy some of Juan's comments....and
post it to the Inbox.

Juan has done a great work .....

--Hannes

==========================================
Category names and class name of Morphic in Cuis
==========================================


('Morphic-Basic'
AlignmentMorph CurveMorph EllipseMorph ImageMorph LineMorph
MinimalStringMorph OneLineEditorMorph PolygonMorph RectangleMorph
SketchMorph StringMorph TransformMorph)

('Morphic-Borders'
BorderStyle InsetBorder RaisedBorder SimpleBorder)

('Morphic-Events'
DropEvent EventHandler KeyboardEvent MorphicAlarm MorphicEvent
MorphicEventDispatcher MorphicUnknownEvent MouseButtonEvent MouseEvent
MouseMoveEvent MouseOverHandler StepMessage UserInputEvent)

('Morphic-Kernel'
 BorderedMorph HandMorph Morph MorphExtension MouseClickState
PluggableMorph TheWorldMenu)

('Morphic-Layouts'
  LayoutFrame)

('Morphic-Menus'
MVCMenuMorph MenuIcons MenuItemMorph MenuLineMorph MenuMorph
UpdatingMenuItemMorph)

('Morphic-Scripting'
  FormsAndHelpsRepository)

('Morphic-Support'
Canvas DamageRecorder EllipseMidpointTracer FormCanvas GrafPort SelectionMorph)

('Morphic-Text Support'
EmptyLine StringMorphEditor TextAnchor TextComposer TextLine TextMorph
TextMorphForEditView)

('Morphic-Widgets'
BalloonMorph ColorPickerMorph HaloMorph HaloSpec HandleMorph
IconicButton NewHandleMorph ProgressBarMorph ProgressMorph
SimpleButtonMorph StarMorph ThreePhaseButtonMorph
UpdatingThreePhaseButtonMorph)

('Morphic-Windows'
AcceptableCleanTextMorph BorderedSubpaneDividerMorph
FillInTheBlankMorph LazyListMorph PluggableButtonMorph
PluggableListMorph PluggableListMorphByItem PluggableListMorphOfMany
PluggableMessageCategoryListMorph PluggableTextMorph PreDebugWindow
ScrollBar ScrollPane ScrollbarButton SystemWindow)

('Morphic-Worlds'
  PasteUpMorph WorldState)

('Morphic-Tests'
  WorldTest)

Hmm. Is this the same taskbar-like morph that loads with Polymorph? I'd be pretty happy to find out which package that's in.

While I miss Polymorph a *lot* less since we've cleaned up the default look and feel, I still feel that our window management is pretty awful. I'd really like to be able to minimize windows, and cycle between them in both directions, without touching the mouse.

I'm aware that I can cycle through windows when no morph has focus and the hand is over the world, but this doesn't help that much when I'm programming, because an editor virtually always has focus, and the reason I want to use the keyboard is specifically so that I don't have to grab the mouse.

I've gone looking for how to do this a few times in the past, but my understanding of the system was insufficient to figure it out every time. Maybe I should try again now.


On Sep 18, 2010, at 4:10 AM, Bert Freudenberg <[hidden email]> wrote:

Jimmie Houchin-5 wrote

I do like the idea of having multiple OS
windows available to the app developer.

See Mars[1]

Jimmie Houchin-5 wrote

So I do understand, certain real world use case requirements for
interfacing outside elements. I just don't believe the UI is really one,
especially when counter examples are so incredibly abundant and are some
of the biggest apps in use anywhere and often written by the OS vendor.

iOS?  Esteban said at ESUG that you must have them to be accepted in the app store

I think whether we individually care or agree with native widgets doesn't matter, and wastes valuable resources that could be put to improving Morphic ;-).  There are people that want them and if we can provide things that people want, great.  I personally won't use native widgets myself for the same reasons you mentioned, but I'm happy to have it as an option.

[1] http://smallworks.com.ar/en/community/Mars

Juan Vuletich-4 wrote

I'd like to be part of that. Are you setting up a mail list?

I'll email you.

Juan Vuletich-4 wrote

Your morph should answer true to #handlesMouseDown: and implement
#mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples
of this in the image already.

Yes, but the handler for my morph will never get called because the TextMorphForShout will handle it first.

Juan Vuletich-4 wrote

You'd really try Cuis. You'll find it much easier to understand and extend.

Cool, I downloaded it at ESUG and started exploring.

Sean P. DeNigris wrote:
> Juan Vuletich-4 wrote:
>  
>> I'd like to be part of that. Are you setting up a mail list?
>>
>>    
> I'll email you.
>  

Thanks.

Oh, yes. May be the simplest would be not to use a PluggableShoutMorph
at all, or make a sibling of it be the container of your morphs.
Otherwise, your morph should be submorph of the TextMorphForShout, but I
guess it would be harder...

> Juan Vuletich-4 wrote:
>  
>> You'd really try Cuis. You'll find it much easier to understand and
>> extend.
>>
>>    
> Cool, I downloaded it at ESUG and started exploring.
>  

Cheers,
Juan Vuletich

On 19.09.2010, at 17:52, Sean P. DeNigris wrote:

> Jimmie Houchin-5 wrote:
>>
>> I do like the idea of having multiple OS
>> windows available to the app developer.
>>
> See Mars[1]

Multiple host windows does nat imply having to have native widgets:

http://wiki.squeak.org/squeak/3862

> Jimmie Houchin-5 wrote:
>>
>> So I do understand, certain real world use case requirements for
>> interfacing outside elements. I just don't believe the UI is really one,
>> especially when counter examples are so incredibly abundant and are some
>> of the biggest apps in use anywhere and often written by the OS vendor.
>>
> iOS?  Esteban said at ESUG that you must have them to be accepted in the app
> store

Many apps (like games, creativity apps) in the App store come with their own UI and do not use iOS widgets.

> I think whether we individually care or agree with native widgets doesn't
> matter, and wastes valuable resources that could be put to improving Morphic
> ;-).  There are people that want them and if we can provide things that
> people want, great.  I personally won't use native widgets myself for the
> same reasons you mentioned, but I'm happy to have it as an option.
>
> [1] http://smallworks.com.ar/en/community/Mars

Yep. Choice is good.

- Bert -

On Fri, Sep 17, 2010 at 12:29 PM, DeNigris Sean <[hidden email]> wrote:
> I was doing a lot of playing with Morphic this week at ESUG in Barcelona.  Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
>
> I think it's amazingly powerful and universally misunderstood.

I totally agree with you.  Morphic is a genius of design.  You get
pixel level control per Morph, hierarchical Morph constructions, and
rich input events, all rendered via an efficient time-based screen
updating (stepping) via frame buffering.  There are multiple levels of
accessibility for developers of varying skill levels.

> 2. I'm not clear whether the hooks for modifying behavior are
>        a. available in all the right places
>        b. working
>        c. widely understood

Before Cuis was available, I would refer to Chapter 2 the "new blue
book" to read how Morphic is "intended" to be used.  Also, the methods
seem to be pretty well categorized in the browser.

> For example, I'm writing an implementorsOf browser that shows the execution path
> as a graph of MethodMorphs connected by LineMorphs, because the standard
> paned browser does not capture the metaphor of drilling down through
> implementors.

Just FYI, yes it does.  Turn on the traceMessages preference in the
Preference Browser.  It doesn't draw lines between the methods, but it
is a very efficient message-tracing browser!

 - Chris

Chris Muller-3 wrote

Just FYI, yes it does.  Turn on the traceMessages preference in the
Preference Browser.  It doesn't draw lines between the methods, but it
is a very efficient message-tracing browser!

I turned it on, but I'm not seeing the difference.  Is this the thing where it scrolls the call chain horizontally?  If so, let me amend:

"because, *for me,* the standard paned browser does not capture the metaphor of drilling down through implementors."

I'm stupid, I need it to draw the lines, ;-)

Sean

> I turned it on, but I'm not seeing the difference.

You didn't?  I've attached a screen shot.  I've been porting the
"Tracing Messages Browser" since the 90's.  The one in Squeak 4.2 is
easily the most productive version of it ever..

> I'm stupid, I need it to draw the lines, ;-)

If you tried traceMessages you might change your mind about wanting
lines...  :-)

 - Chris

Obviously somehting is broken with my image regarding png files and so
now I'm frustrated, sorry.

But, Sean, I think if you will give it 5 minutes you will see it.
Just turn on traceMessages, then browse implementors of some message.
Then, highlight the  message (in the lower pane) that you want to
"drill down" and press Command+M.

Senders works the same, but only from the top pane (this is on purpose).

IMO, there has never been a more productive message tracing browser.
Not Trailblazer, not OB, not Eclipse..

On Mon, Sep 20, 2010 at 3:02 PM, Chris Muller <[hidden email]> wrote:

On 9/22/10, Chris Muller <[hidden email]> wrote:
The chapter is still a good introduction. The only thing is that now
every Morph has the capability to do the layout of its submorphs. So
there is no need for an AlignmentMorph anymore.

Class comment of AlignmentMorph in current Squeak 4.1
"Used for layout.
Since all morphs now support layoutPolicy the main use of this class
is no longer needed.
Kept around for compability.
Supports a few methods not found elsewhere that can be convenient, eg. newRow
"


See also some info which still holds on

http://wiki.squeak.org/squeak/1820   (Morph)

http://wiki.squeak.org/squeak/1285 (Morphic Architecture)

Thank you Sean, for bringing up this topic,

joining a bit late, here a few remarks.

--Hannes

On 9/17/10, DeNigris Sean <[hidden email]> wrote:
> I was doing a lot of playing with Morphic this week at ESUG in Barcelona.
> Many people seem to really not like it and complain about it, but it seems
> very vague i.e. they can't point to a specific problem with it.
>
> I think it's amazingly powerful and universally misunderstood.  Many people
> are pushing for native widgets for end users, which I think is awesome, but
> serves a different role.  For me, there are two use cases:
> 1. People (mostly Smalltalkers, including myself) interested in the UI's of
> the future and exploring what's possible

Yes,

> 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g.
> enterprise) where they have to use a particular GUI.

Yes

Which method did you like best?

There are some notes on this issue at
http://wiki.squeak.org/squeak/2477
( Eddie Cottongim writes: I know of three main ways to handle events
in Morphic.......)

I assume Juan does not have this variety anymore in his CUIS image.....


Conclusion: It might be worthwile to find out more how Juan has pruned
Morphic in Cuis and if it is still valuable for use, document that and
put it to use in Squeak and Pharo.

I have started reading the Cuis code, it is helpful for understanding
Morphic and once you know your way around you do not mind so much that
there are a lot of other things.

Hi. :)

On Fri, Sep 17, 2010 at 12:29 PM, DeNigris Sean wrote:

> I was doing a lot of playing with Morphic this week at ESUG in Barcelona.
> Many people seem to really not like it and complain about it, but it seems
> very vague i.e. they can't point to a specific problem with it.

Morphic needs a more convenient way of UI programming. The tool builder
makes
you write code that, in my opinion, would only be acceptable if a real
tool generated that code for you after a drag&drop-design-session with your
mouse.
It shouldn't be necessary to write wrapper classes (*Spec) that are only
able
to compose morphs. That makes the code difficult to manage. It takes too
much time
to locate the part of the source code that is responsible for showing button
X in
window Y.

Every morph should have its own coordinate system. It is quite
difficult to consider all special cases (TransformMorph,
#globalPointToLocal:, ...)
and even impossible to write some applications in a clean fashion.

The layout mechanism is broken somehow. The API for table layout is
really good but does not work as expected in some cases, as it needs one
world cycle
or even a change of some values (e.g., #extent) until coordinates and
dimensions
become valid and can be accessed for further computations.

The managing of fonts and font rendering in general needs more attention I
think. The
default font in Squeak 4.1 looks quite good but has too few different sizes.
At least
one good-looking mono-spaced font would be great. :)

Ciao,
Marcel Taeumel