Smalltalk › Pharo › Pharo Smalltalk Developers

About SimpleMorphic

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Juan Vuletich-4

About SimpleMorphic

Hi Folks,

I apologize for not answering the original messages properly, I had mail
deliver disabled, so I can't. I have enabled it, so I'll answer properly
from now on.

To Hillarie:
If you don't use Polymorph, but want to build your own Morphs from
scratch, SimpleMorphic is simpler, easier to understand, tweak and fix.

To Doru:
Let's do a comparison:

Size of 4 core classes (Morph, MorphExtension, PasteUpMorph and WorldState)
Pharo / Squeak / Cuis
totalIvars: 39 / 46 / 26
totalClassVars: 15 / 10 / 5
totalInstMethods: 1170 / 1764 / 663
totalClassMethods: 55 / 71 / 16

Size of the whole Morph hierarchy
Pharo / Squeak / Cuis
totalClasses: 197 / 331 / 58
totalIvars: 649 / 1063 / 257
totalClassVars: 54 / 138 / 28
totalInstMethods: 6651 / 9186 / 2115
totalClassMethods: 303 / 858 / 127

SimpleMorphic is much smaller. Core classes are simpler and easier to
understand, fix and extend. The most important part is that this is not
blind removal of unused code. A lot of the functionality has been
redesigned to make it simpler, and the removal was done with great care
to result in a consistent system. This work started in 2004, so we're
talking of about 6 years of careful work. All this means that
SimpleMorphic does not support all the features that Pharo or Squeak
might support. Please use the browsers and other tools in Cuis to check
what it indeed can do.

Talking about complexity, let's take for example, morph layout. This is
started with #doLayoutIn: in Pharo and #doLayoutIfNeeded in SimpleMorphic.

In Pharo, this method calls #adjustLayoutBounds: (19), #layout:in:
(149), #layoutProportionallyIn: (10),
#computeCellArrangement:in:horizontal:target: (87),
#computeGlobalCellArrangement:in:horizontal:wrap:spacing: (31),
#computeCellSizes:in:horizontal: (30),
#computeExtraSpacing:in:horizontal:target: (136), #layoutLeftToRight:in:
(91), #layoutTopToBottom:in: (91), #placeCells:in:horizontal:target:
(70). The numbers in parenthesis are the sum of the lines of code of the
implementors. Total lines of code for layout (taking only these most
important methods) is 714. I doubt there are many people who really
understand all of this code.

In SimpleMorphic (Cuis), this calls #layoutSubmorphsIn: (10),
#applyLayoutFrameIn: (11), #layout:in: (24). Total lines of code is 45.
I believe any smalltalker could understand these in just minutes.

I hope this makes makes it clearer to you what SimpleMorphic is.

Cheers,
Juan Vuletich

Douglas Brebner

Re: About SimpleMorphic

On 07/11/2010 03:17, Juan Vuletich wrote:

>
> In Pharo, this method calls #adjustLayoutBounds: (19), #layout:in:
> (149), #layoutProportionallyIn: (10),
> #computeCellArrangement:in:horizontal:target: (87),
> #computeGlobalCellArrangement:in:horizontal:wrap:spacing: (31),
> #computeCellSizes:in:horizontal: (30),
> #computeExtraSpacing:in:horizontal:target: (136),
> #layoutLeftToRight:in: (91), #layoutTopToBottom:in: (91),
> #placeCells:in:horizontal:target: (70). The numbers in parenthesis are
> the sum of the lines of code of the implementors. Total lines of code
> for layout (taking only these most important methods) is 714. I doubt
> there are many people who really understand all of this code.
>
> In SimpleMorphic (Cuis), this calls #layoutSubmorphsIn: (10),
> #applyLayoutFrameIn: (11), #layout:in: (24). Total lines of code is
> 45. I believe any smalltalker could understand these in just minutes.
>
> I hope this makes makes it clearer to you what SimpleMorphic is.
>
>

This sounds awesome, Morphics' complexity has long been a sticking point
of mine.

Thanks for doing this :)

Igor Stasenko

Re: About SimpleMorphic

In reply to this post by Juan Vuletich-4

On 7 November 2010 05:17, Juan Vuletich <[hidden email]> wrote:

> Hi Folks,
>
> I apologize for not answering the original messages properly, I had mail
> deliver disabled, so I can't. I have enabled it, so I'll answer properly
> from now on.
>
> To Hillarie:
> If you don't use Polymorph, but want to build your own Morphs from scratch,
> SimpleMorphic is simpler, easier to understand, tweak and fix.
>
>
> To Doru:
> Let's do a comparison:
>
> Size of 4 core classes (Morph, MorphExtension, PasteUpMorph and WorldState)
> Pharo / Squeak / Cuis
> totalIvars: 39 / 46 / 26
> totalClassVars: 15 / 10 / 5
> totalInstMethods: 1170 / 1764 / 663
> totalClassMethods: 55 / 71 / 16
>
> Size of the whole Morph hierarchy
> Pharo / Squeak / Cuis
> totalClasses: 197 / 331 / 58
> totalIvars: 649 / 1063 / 257
> totalClassVars: 54 / 138 / 28
> totalInstMethods: 6651 / 9186 / 2115
> totalClassMethods: 303 / 858 / 127
>
> SimpleMorphic is much smaller. Core classes are simpler and easier to
> understand, fix and extend. The most important part is that this is not
> blind removal of unused code. A lot of the functionality has been redesigned
> to make it simpler, and the removal was done with great care to result in a
> consistent system. This work started in 2004, so we're talking of about 6
> years of careful work. All this means that SimpleMorphic does not support
> all the features that Pharo or Squeak might support. Please use the browsers
> and other tools in Cuis to check what it indeed can do.
>
> Talking about complexity, let's take for example, morph layout. This is
> started with #doLayoutIn: in Pharo and #doLayoutIfNeeded in SimpleMorphic.
>
> In Pharo, this method calls #adjustLayoutBounds: (19), #layout:in: (149),
> #layoutProportionallyIn: (10), #computeCellArrangement:in:horizontal:target:
> (87), #computeGlobalCellArrangement:in:horizontal:wrap:spacing: (31),
> #computeCellSizes:in:horizontal: (30),
> #computeExtraSpacing:in:horizontal:target: (136), #layoutLeftToRight:in:
> (91), #layoutTopToBottom:in: (91), #placeCells:in:horizontal:target: (70).
> The numbers in parenthesis are the sum of the lines of code of the
> implementors. Total lines of code for layout (taking only these most
> important methods) is 714. I doubt there are many people who really
> understand all of this code.
>
> In SimpleMorphic (Cuis), this calls #layoutSubmorphsIn: (10),
> #applyLayoutFrameIn: (11), #layout:in: (24). Total lines of code is 45. I
> believe any smalltalker could understand these in just minutes.
>

Indeed, a morphic layout logic always felt overly complicated to me.
It hard, because you don't know,
if you can remove/replace anything from there and still have a working
code. Good to see that you have managed to deal with that.

> I hope this makes makes it clearer to you what SimpleMorphic is.
>
> Cheers,
> Juan Vuletich
>
>

--
Best regards,
Igor Stasenko AKA sig.

Nicolas Cellier

Re: About SimpleMorphic

2010/11/7 Igor Stasenko <[hidden email]>:

>> Talking about complexity, let's take for example, morph layout. This is
>> started with #doLayoutIn: in Pharo and #doLayoutIfNeeded in SimpleMorphic.
>>
>> In Pharo, this method calls #adjustLayoutBounds: (19), #layout:in: (149),
>> #layoutProportionallyIn: (10), #computeCellArrangement:in:horizontal:target:
>> (87), #computeGlobalCellArrangement:in:horizontal:wrap:spacing: (31),
>> #computeCellSizes:in:horizontal: (30),
>> #computeExtraSpacing:in:horizontal:target: (136), #layoutLeftToRight:in:
>> (91), #layoutTopToBottom:in: (91), #placeCells:in:horizontal:target: (70).
>> The numbers in parenthesis are the sum of the lines of code of the
>> implementors. Total lines of code for layout (taking only these most
>> important methods) is 714. I doubt there are many people who really
>> understand all of this code.
>>
>> In SimpleMorphic (Cuis), this calls #layoutSubmorphsIn: (10),
>> #applyLayoutFrameIn: (11), #layout:in: (24). Total lines of code is 45. I
>> believe any smalltalker could understand these in just minutes.
>>
>
> Indeed, a morphic layout logic always felt overly complicated to me.
> It hard, because you don't know,
> if you can remove/replace anything from there and still have a working
> code. Good to see that you have managed to deal with that.
>

The question that immediately arises from such complexity is :
- what are the features we want to implement ?

If we are not able to provide an answer, that means we can't even
write tests, and that also means we can't modify/refactor the code.
In such case, we tend to write more code outside existing one and so
doing are just making things worse (more code more complexity).

I suspect (but I did not check) that Juan's work in Cuis is the best
thing to do in such case.
While at it, we should also write tests now that we have testable features.

Nicolas

Igor Stasenko

Re: About SimpleMorphic

On 7 November 2010 21:17, Nicolas Cellier
<[hidden email]> wrote:

> 2010/11/7 Igor Stasenko <[hidden email]>:
>>> Talking about complexity, let's take for example, morph layout. This is
>>> started with #doLayoutIn: in Pharo and #doLayoutIfNeeded in SimpleMorphic.
>>>
>>> In Pharo, this method calls #adjustLayoutBounds: (19), #layout:in: (149),
>>> #layoutProportionallyIn: (10), #computeCellArrangement:in:horizontal:target:
>>> (87), #computeGlobalCellArrangement:in:horizontal:wrap:spacing: (31),
>>> #computeCellSizes:in:horizontal: (30),
>>> #computeExtraSpacing:in:horizontal:target: (136), #layoutLeftToRight:in:
>>> (91), #layoutTopToBottom:in: (91), #placeCells:in:horizontal:target: (70).
>>> The numbers in parenthesis are the sum of the lines of code of the
>>> implementors. Total lines of code for layout (taking only these most
>>> important methods) is 714. I doubt there are many people who really
>>> understand all of this code.
>>>
>>> In SimpleMorphic (Cuis), this calls #layoutSubmorphsIn: (10),
>>> #applyLayoutFrameIn: (11), #layout:in: (24). Total lines of code is 45. I
>>> believe any smalltalker could understand these in just minutes.
>>>
>>
>> Indeed, a morphic layout logic always felt overly complicated to me.
>> It hard, because you don't know,
>> if you can remove/replace anything from there and still have a working
>> code. Good to see that you have managed to deal with that.
>>
>
> The question that immediately arises from such complexity is :
> - what are the features we want to implement ?
>
> If we are not able to provide an answer, that means we can't even
> write tests, and that also means we can't modify/refactor the code.
> In such case, we tend to write more code outside existing one and so
> doing are just making things worse (more code more complexity).
>
> I suspect (but I did not check) that Juan's work in Cuis is the best
> thing to do in such case.
> While at it, we should also write tests now that we have testable features.
>

it is hard to say, what layout policies we may need, and what can be
removed/simplified. What i feel wrong with scheme,
that from message names it feels like a container morph is responsible
for layout,
while i think, that it is submorph(s) themselves should be responsible
and know how to place
them within parent morph.

> Nicolas
>
>

--
Best regards,
Igor Stasenko AKA sig.

Schwab,Wilhelm K

Re: About SimpleMorphic

Sig,

I disagree; the layout policy should arrange the morphs it controls. To do otherwise demands that the morphs be able to cope with any type of layout one might want. The various algorithms have to go somewhere; they might as well go in the layouts.

Bill

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
Sent: Sunday, November 07, 2010 2:50 PM
To: [hidden email]
Subject: Re: [Pharo-project] About SimpleMorphic

it is hard to say, what layout policies we may need, and what can be
removed/simplified. What i feel wrong with scheme,
that from message names it feels like a container morph is responsible
for layout,
while i think, that it is submorph(s) themselves should be responsible
and know how to place
them within parent morph.

Igor Stasenko

Re: About SimpleMorphic

On 7 November 2010 22:38, Schwab,Wilhelm K <[hidden email]> wrote:
> Sig,
>
> I disagree; the layout policy should arrange the morphs it controls. To do otherwise demands that the morphs be able to cope with any type of layout one might want. The various algorithms have to go somewhere; they might as well go in the layouts.
>

Some layouts, like table, indeed requiring a cooperation between
container morph and its submorphs.

But still, i think that it should be based on a simple things:
- morph should have a single layout command: lay within certain
bounds. It doesn't matters where these bounds came from or how they
are calculated.

Then child morph could decide for itself how to lay within given
bounds (like fill whole area or align to botton or top etc etc), and
avoid querying parent morph or layout policy/whatever to determine own
bounds, unless, of course it also having submorphs and own layout
policy.

So, if parent morph having no layout policy, it will simply pass its
own bounds to submoprhs.
And if parent having , say table layout policy, then it will calculate
table cells and pass each cell bounds to each submorph for given cell.

and yes, implementing this stuff is always harder than just talking about it :)

> Bill
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
> Sent: Sunday, November 07, 2010 2:50 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] About SimpleMorphic
>
>
>
> it is hard to say, what layout policies we may need, and what can be
> removed/simplified. What i feel wrong with scheme,
> that from message names it feels like a container morph is responsible
> for layout,
> while i think, that it is submorph(s) themselves should be responsible
> and know how to place
> them within parent morph.
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Juan Vuletich-4

Re: About SimpleMorphic

Hi Folks,

WRT Layout APIs, SimpleMorphic includes the same simplified version of
LayoutFrame as Cuis.

Cuis also includes a new approach, implemented in LayoutSpec and
LayoutMorph. I did this for an application that requies adding new
widgets without specifying a new layout for all of them. It is also
nicer than LayoutFrame, and will replace it at some moment. But it is
not used at all by SimpleMorphic or Cuis, and that's why I did not
include it in SimpleMorphic for Pharo. But you might open Cuis and take
a look it, and load it in Pharo if you like. Try the example class
methods in LayoutMorph, and resize the morph to see what it can do.

Cheers,
Juan Vuletich

Denis Kudriashov

Re: About SimpleMorphic

In reply to this post by Igor Stasenko

2010/11/8 Igor Stasenko <[hidden email]>

On 7 November 2010 22:38, Schwab,Wilhelm K <[hidden email]> wrote:
> Sig,
>
> I disagree; the layout policy should arrange the morphs it controls. To do otherwise demands that the morphs be able to cope with any type of layout one might want. The various algorithms have to go somewhere; they might as well go in the layouts.
>

Some layouts, like table, indeed requiring a cooperation between
container morph and its submorphs.

But still, i think that it should be based on a simple things:
- morph should have a single layout command: lay within certain
bounds. It doesn't matters where these bounds came from or how they
are calculated.

Then child morph could decide for itself how to lay within given
bounds (like fill whole area or align to botton or top etc etc), and
avoid querying parent morph or layout policy/whatever to determine own
bounds, unless, of course it also having submorphs and own layout
policy.

So, if parent morph having no layout policy, it will simply pass its
own bounds to submoprhs.
And if parent having , say table layout policy, then it will calculate
table cells and pass each cell bounds to each submorph for given cell.

and yes, implementing this stuff is always harder than just talking about it :)

I remember interesting design for layout logic in newspeak Brazil framefork.

http://blog.3plus4.org/2008/11/23/brazil-example-a-classic-smalltalk-browser/

See part about "area" concept

Fernando olivero-2

Re: About SimpleMorphic

In reply to this post by Juan Vuletich-4

Hi Juan, i have a couple of questions regarding the new Cuis layout,
which by the way , is a much cleaner implementation!.

"LayoutSpecs are the basis for a new layout mechanism, alternative to
LayoutFrame. Any Morph can be given a LayoutSpec, but in order to
honor it, the morph must be submorph of a LayoutMorph."

In my opinion, we dont need to enforce the LayoutMorph subclasification.
Because Morph>>doLayoutIfNeeded could use its "layoutMorphSpec"
collaborator, if present.

doLayoutIfNeeded
...
[self layoutSpec layoutSubmorphsIn: self layoutBounds] on: Error do: [ :ex |
...
What do you think?

Fernando

pd: Similar to decoupling the "visual layout properties" that Brazil is doing.

On Mon, Nov 8, 2010 at 3:05 PM, Juan Vuletich <[hidden email]> wrote:

> Hi Folks,
>
> WRT Layout APIs, SimpleMorphic includes the same simplified version of
> LayoutFrame as Cuis.
>
> Cuis also includes a new approach, implemented in LayoutSpec and
> LayoutMorph. I did this for an application that requies adding new
> widgets without specifying a new layout for all of them. It is also
> nicer than LayoutFrame, and will replace it at some moment. But it is
> not used at all by SimpleMorphic or Cuis, and that's why I did not
> include it in SimpleMorphic for Pharo. But you might open Cuis and take
> a look it, and load it in Pharo if you like. Try the example class
> methods in LayoutMorph, and resize the morph to see what it can do.
>
> Cheers,
> Juan Vuletich
>
>

Juan Vuletich-4

Re: About SimpleMorphic

Hi Fernando,

Fernando Olivero wrote:
> Hi Juan, i have a couple of questions regarding the new Cuis layout,
> which by the way , is a much cleaner implementation!.
>

Good! Did you play a bit with the examples in LayoutMorph class methods?
They are kinda cool. For instance, do LayoutMorph example3, enlarge the
morph and remove some of the submorphs, and see how the layout adjust
itself.

> "LayoutSpecs are the basis for a new layout mechanism, alternative to
> LayoutFrame. Any Morph can be given a LayoutSpec, but in order to
> honor it, the morph must be submorph of a LayoutMorph."
>
> In my opinion, we dont need to enforce the LayoutMorph subclasification.
>

Well, I guess you misread. I didn't say 'subclass of LayoutMorph'. I
said 'submorph of a LayoutMorph' :)

> Because Morph>>doLayoutIfNeeded could use its "layoutMorphSpec"
> collaborator, if present.
>
> doLayoutIfNeeded
> ...
> [self layoutSpec layoutSubmorphsIn: self layoutBounds] on: Error do: [ :ex |
> ...
> What do you think?
>
> Fernando
>
> pd: Similar to decoupling the "visual layout properties" that Brazil is doing.
>

Well, LayoutSpec is quite like what Brazil does. For example, from the
Brazil description: "When the same visual is a child of a Row, the area
is an instance of a different class whose attributes and behavior are
meaningful for a row cell." Looks like the main difference is that I
merged the Row object and the Area object in the LayoutMorph object.

Cheers,
Juan Vuletich
Ps. Do you happen to be in Buenos Aires these days? We'd meet!

> On Mon, Nov 8, 2010 at 3:05 PM, Juan Vuletich <[hidden email]> wrote:
>
>> Hi Folks,
>>
>> WRT Layout APIs, SimpleMorphic includes the same simplified version of
>> LayoutFrame as Cuis.
>>
>> Cuis also includes a new approach, implemented in LayoutSpec and
>> LayoutMorph. I did this for an application that requies adding new
>> widgets without specifying a new layout for all of them. It is also
>> nicer than LayoutFrame, and will replace it at some moment. But it is
>> not used at all by SimpleMorphic or Cuis, and that's why I did not
>> include it in SimpleMorphic for Pharo. But you might open Cuis and take
>> a look it, and load it in Pharo if you like. Try the example class
>> methods in LayoutMorph, and resize the morph to see what it can do.
>>
>> Cheers,
>> Juan Vuletich
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.864 / Virus Database: 271.1.1/3246 - Release Date: 11/09/10 04:34:00
>>
>>

Fernando olivero-2

Re: About SimpleMorphic

I just ran the examples, and just can say...NICE!!

m := LayoutMorph example3
m width: 400.
m width: 600.
row := m submorphs anyOne.
row submorphs last delete.
row delete.
m delete.

I've just added these lines to the example. You can find the minor
changes in the attached changeset.

AH! i've misread the submorph of LayoutMorph part.

Still i think that LayoutMorph does not necessarily have to be a
Morph, because it only has the responsibility of laying out a group of
"rectangles" right? My comments were in this direction, to decouple
LayoutMorph from Morph. I couldn't tell if Brazil's Area is a "Brazil
visual", but i ask why not decuple it?

When i did my own GauchoLayouts i've implemented like this, but now i
would like ditch them and use your classes and merge them with Morph.

Fernando
pd: i couldnt go to Smalltalks this year, so sadly i wont see you next
talk on Morphic3.0?

I will continue to play with you layout morphs, and possibly adapt
them to Pharo.
Fernando
On Tue, Nov 9, 2010 at 4:58 PM, Juan Vuletich <[hidden email]> wrote:

> Hi Fernando,
>
> Fernando Olivero wrote:
>> Hi Juan, i have a couple of questions regarding the new Cuis layout,
>> which by the way , is a much cleaner implementation!.
>>
>
> Good! Did you play a bit with the examples in LayoutMorph class methods?
> They are kinda cool. For instance, do LayoutMorph example3, enlarge the
> morph and remove some of the submorphs, and see how the layout adjust
> itself.
>
>> "LayoutSpecs are the basis for a new layout mechanism, alternative to
>> LayoutFrame. Any Morph can be given a LayoutSpec, but in order to
>> honor it, the morph must be submorph of a LayoutMorph."
>>
>> In my opinion, we dont need to enforce the LayoutMorph subclasification.
>>
>
> Well, I guess you misread. I didn't say 'subclass of LayoutMorph'. I
> said 'submorph of a LayoutMorph' :)
>
>> Because Morph>>doLayoutIfNeeded could use its "layoutMorphSpec"
>> collaborator, if present.
>>
>> doLayoutIfNeeded
>> ...
>> [self layoutSpec layoutSubmorphsIn: self layoutBounds] on: Error do: [ :ex |
>> ...
>> What do you think?
>>
>> Fernando
>>
>> pd: Similar to decoupling the "visual layout properties" that Brazil is doing.
>>
>
> Well, LayoutSpec is quite like what Brazil does. For example, from the
> Brazil description: "When the same visual is a child of a Row, the area
> is an instance of a different class whose attributes and behavior are
> meaningful for a row cell." Looks like the main difference is that I
> merged the Row object and the Area object in the LayoutMorph object.
>
> Cheers,
> Juan Vuletich
> Ps. Do you happen to be in Buenos Aires these days? We'd meet!
>
>> On Mon, Nov 8, 2010 at 3:05 PM, Juan Vuletich <[hidden email]> wrote:
>>
>>> Hi Folks,
>>>
>>> WRT Layout APIs, SimpleMorphic includes the same simplified version of
>>> LayoutFrame as Cuis.
>>>
>>> Cuis also includes a new approach, implemented in LayoutSpec and
>>> LayoutMorph. I did this for an application that requies adding new
>>> widgets without specifying a new layout for all of them. It is also
>>> nicer than LayoutFrame, and will replace it at some moment. But it is
>>> not used at all by SimpleMorphic or Cuis, and that's why I did not
>>> include it in SimpleMorphic for Pharo. But you might open Cuis and take
>>> a look it, and load it in Pharo if you like. Try the example class
>>> methods in LayoutMorph, and resize the morph to see what it can do.
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 9.0.864 / Virus Database: 271.1.1/3246 - Release Date: 11/09/10 04:34:00
>>>
>>>
>
>
>

LayoutMorph examples.1.cs (1K) Download Attachment

Hannes Hirzel

Re: About SimpleMorphic

On 11/10/10, Fernando Olivero <[hidden email]> wrote:

....

> Still i think that LayoutMorph does not necessarily have to be a
> Morph, because it only has the responsibility of laying out a group of
> "rectangles" right? My comments were in this direction, to decouple
> LayoutMorph from Morph. I couldn't tell if Brazil's Area is a "Brazil
> visual", but i ask why not decuple it?

Good question --- I am curious to see what the answers will be.....

--Hannes

Juan Vuletich-4

Re: About SimpleMorphic

In reply to this post by Fernando olivero-2

Hi Fernando,

Fernando Olivero wrote:

> I just ran the examples, and just can say...NICE!!
>
> m := LayoutMorph example3
> m width: 400.
> m width: 600.
> row := m submorphs anyOne.
> row submorphs last delete.
> row delete.
> m delete.
>
> I've just added these lines to the example. You can find the minor
> changes in the attached changeset.
>

Thanks!

> AH! i've misread the submorph of LayoutMorph part.
>
> Still i think that LayoutMorph does not necessarily have to be a
> Morph, because it only has the responsibility of laying out a group of
> "rectangles" right? My comments were in this direction, to decouple
> LayoutMorph from Morph. I couldn't tell if Brazil's Area is a "Brazil
> visual", but i ask why not decuple it?
>

That would be an interesting experiment. I guess these non-morph object
in the morph / submorphs tree will need to support many messages of the
Morph protocol. I guess someone needs to do it and see if the results
are good. Go for it!

> When i did my own GauchoLayouts i've implemented like this, but now i
> would like ditch them and use your classes and merge them with Morph.
>

You already did non-morph objects in the submorph tree? How was the
result? Do you like it? Can we see the code?

> Fernando
> pd: i couldnt go to Smalltalks this year, so sadly i wont see you next
> talk on Morphic3.0?
>

Well, I'm not giving a talk this year, so at least you're not missing
that :(

> I will continue to play with you layout morphs, and possibly adapt
> them to Pharo.
> Fernando

Great!

Cheers,
Juan Vuletich