[Please Review] Many fixes for Morphic's layout

Hi, there,

Hey Chris (cmm) :-) Would you try it out on some important interactions in Maui?

Am 12.08.2019 18:30:51 schrieb Marcel Taeumel <[hidden email]>:

Hi, there,

Please find attached a change set that addresses several bugs around layouting and re-drawing. I had the following goals:

- Better support for TextMorphs in TableLayout

- Better support for protruding submorphs in a non-clipping and non-shrink-wrapping morph

- Ensure full layout computation after calling #fullBounds ... no extra re-draw cycles to avoid flickering.

I have to admit that I did break some layout things back in 2016 because I didn't understand the implementation good enough. Other things have never been working correctly before, such as height-for-width updates for TextMorph children ... which do their own (text) layout and thus misbehaved in a table-layout container.

What's (still) not working?

- Useful minimum extent for windows and dialogs

- #justified list-centering with #spaceFill children (-> might be a new issue but rare?)

How can you test some changes? Well, try resizing the find-class or save-file dialog to this:

Usually, submorphs are either not protruding their morphs or they get clipped. If they are protruding and not clipped, the layout-cell computation was a mix of bounds and fullBounds. I suppose that other frameworks use just the bounds, ignoring any protruding submorphs, like this:

The blue-filled morphs are shrink-wrapped in a container arranged from the left to the right. Protruding submorphs share the owner's border color. Only the rightmost morph has its own table layout and adjuts its height to its children -- but not its width.

Best,

Marcel

Please find attached an updated version.

Am 14.08.2019 08:51:29 schrieb Marcel Taeumel <[hidden email]>:

Hey Chris (cmm) :-) Would you try it out on some important interactions in Maui?

Hey Tim (tpr) :-) Would you make a short performance check on a RaspberryPi?

Best,

Marcel

Am 12.08.2019 18:30:51 schrieb Marcel Taeumel <[hidden email]>:

Hi, there,

Please find attached a change set that addresses several bugs around layouting and re-drawing. I had the following goals:

- Better support for TextMorphs in TableLayout

- Better support for protruding submorphs in a non-clipping and non-shrink-wrapping morph

- Ensure full layout computation after calling #fullBounds ... no extra re-draw cycles to avoid flickering.

I have to admit that I did break some layout things back in 2016 because I didn't understand the implementation good enough. Other things have never been working correctly before, such as height-for-width updates for TextMorph children ... which do their own (text) layout and thus misbehaved in a table-layout container.

What's (still) not working?

- Useful minimum extent for windows and dialogs

- #justified list-centering with #spaceFill children (-> might be a new issue but rare?)

How can you test some changes? Well, try resizing the find-class or save-file dialog to this:

Usually, submorphs are either not protruding their morphs or they get clipped. If they are protruding and not clipped, the layout-cell computation was a mix of bounds and fullBounds. I suppose that other frameworks use just the bounds, ignoring any protruding submorphs, like this:

The blue-filled morphs are shrink-wrapped in a container arranged from the left to the right. Protruding submorphs share the owner's border color. Only the rightmost morph has its own table layout and adjuts its height to its children -- but not its width.

Best,

Marcel

Not possible. #cellSpacing (#globalRect, #globalSquare, #localRect, #localSquare) has already another meaning in TableLayout. :-)

Am 21.08.2019 16:58:24 schrieb Fabio Niephaus <[hidden email]>:

On Wed, 21 Aug 2019 at 4:58 pm, Marcel Taeumel <[hidden email]> wrote:

Please find attached an updated version.

Biggest changes:

- Fixes a bug with #cellInset in TableLayout

- Adds new property #cellGap for TableLayout

+1 for calling this cellSpacing instead (similar to HTML tables).

- Uses #cellGap instead of #cellInset in most cases

Best,

Marcel

Am 14.08.2019 08:51:29 schrieb Marcel Taeumel <[hidden email]>:

Hey Chris (cmm) :-) Would you try it out on some important interactions in Maui?

Hey Tim (tpr) :-) Would you make a short performance check on a RaspberryPi?

Best,

Marcel

Am 12.08.2019 18:30:51 schrieb Marcel Taeumel <[hidden email]>:

Hi, there,

Please find attached a change set that addresses several bugs around layouting and re-drawing. I had the following goals:

- Better support for TextMorphs in TableLayout

- Better support for protruding submorphs in a non-clipping and non-shrink-wrapping morph

- Ensure full layout computation after calling #fullBounds ... no extra re-draw cycles to avoid flickering.

I have to admit that I did break some layout things back in 2016 because I didn't understand the implementation good enough. Other things have never been working correctly before, such as height-for-width updates for TextMorph children ... which do their own (text) layout and thus misbehaved in a table-layout container.

What's (still) not working?

- Useful minimum extent for windows and dialogs

- #justified list-centering with #spaceFill children (-> might be a new issue but rare?)

How can you test some changes? Well, try resizing the find-class or save-file dialog to this:

Usually, submorphs are either not protruding their morphs or they get clipped. If they are protruding and not clipped, the layout-cell computation was a mix of bounds and fullBounds. I suppose that other frameworks use just the bounds, ignoring any protruding submorphs, like this:

The blue-filled morphs are shrink-wrapped in a container arranged from the left to the right. Protruding submorphs share the owner's border color. Only the rightmost morph has its own table layout and adjuts its height to its children -- but not its width.

Best,

Marcel

Since all those #cell* properties use the same values for all cells in an owner, there is no property that would compare to CSS margin. There is CSS padding, though, in the form of #layoutInset, which is "per cell" or morph. I am not sure whether #cellInset exists in the CSS world. Maybe there is no need because of CSS margin.

Am 21.08.2019 17:16:37 schrieb Marcel Taeumel <[hidden email]>:

Not possible. #cellSpacing (#globalRect, #globalSquare, #localRect, #localSquare) has already another meaning in TableLayout. :-)

Best,

Marcel

Am 21.08.2019 16:58:24 schrieb Fabio Niephaus <[hidden email]>:

On Wed, 21 Aug 2019 at 4:58 pm, Marcel Taeumel <[hidden email]> wrote:

Please find attached an updated version.

Biggest changes:

- Fixes a bug with #cellInset in TableLayout

- Adds new property #cellGap for TableLayout

+1 for calling this cellSpacing instead (similar to HTML tables).

- Uses #cellGap instead of #cellInset in most cases

Best,

Marcel

Am 14.08.2019 08:51:29 schrieb Marcel Taeumel <[hidden email]>:

Hey Chris (cmm) :-) Would you try it out on some important interactions in Maui?

Hey Tim (tpr) :-) Would you make a short performance check on a RaspberryPi?

Best,

Marcel

Am 12.08.2019 18:30:51 schrieb Marcel Taeumel <[hidden email]>:

Hi, there,

Please find attached a change set that addresses several bugs around layouting and re-drawing. I had the following goals:

- Better support for TextMorphs in TableLayout

- Better support for protruding submorphs in a non-clipping and non-shrink-wrapping morph

- Ensure full layout computation after calling #fullBounds ... no extra re-draw cycles to avoid flickering.

I have to admit that I did break some layout things back in 2016 because I didn't understand the implementation good enough. Other things have never been working correctly before, such as height-for-width updates for TextMorph children ... which do their own (text) layout and thus misbehaved in a table-layout container.

What's (still) not working?

- Useful minimum extent for windows and dialogs

- #justified list-centering with #spaceFill children (-> might be a new issue but rare?)

How can you test some changes? Well, try resizing the find-class or save-file dialog to this:

Usually, submorphs are either not protruding their morphs or they get clipped. If they are protruding and not clipped, the layout-cell computation was a mix of bounds and fullBounds. I suppose that other frameworks use just the bounds, ignoring any protruding submorphs, like this:

The blue-filled morphs are shrink-wrapped in a container arranged from the left to the right. Protruding submorphs share the owner's border color. Only the rightmost morph has its own table layout and adjuts its height to its children -- but not its width.

Best,

Marcel

I just merged the changes into Trunk. Keep me updated about any upcoming issues.

Am 22.08.2019 08:33:38 schrieb Marcel Taeumel <[hidden email]>:

Further thoughts in this topic: 

Since all those #cell* properties use the same values for all cells in an owner, there is no property that would compare to CSS margin. There is CSS padding, though, in the form of #layoutInset, which is "per cell" or morph. I am not sure whether #cellInset exists in the CSS world. Maybe there is no need because of CSS margin.

Comparing to the CSS box model, the biggest difference to Squeak's Morphic is the size (or extent) calculation. In CSS, "... width: 50px ..."  refers to the "inner-most" bounds, which are the #layoutBounds in Squeak. Evaluating "aMorph width: 50" in Squeak will make that morph 50px wide, while CSS would add margin, border width, and padding ... making it 50 px + ?? px

I think that Squeak's way of treating #width: and #height: is easier for the programmer. However, this would mean that any "margin" had to be implemented close to BorderStyle. Inset the border style. Then, #width: and #height: could keep their current meaning.

Note that there is Morph >> #layoutBounds: but that is used only for the layouting process. Hmm...  maybe I change #layoutBounds:, #layoutPosition:, and #layoutExtent: to #setLayoutBounds:, #setLayoutPosition:, and #setLayoutExtent: to make that more clear.

Maybe we need something that compares to CSS "... width: 50px ..." such as Morph >> #innerWidth:. ... no, that would include only border inset (see Morph >> #innerBounds) not #layoutInset ... maybe Morph >> #layoutWidth:. ... and so on. :-)

Best,

Marcel

Am 21.08.2019 17:16:37 schrieb Marcel Taeumel <[hidden email]>:

Not possible. #cellSpacing (#globalRect, #globalSquare, #localRect, #localSquare) has already another meaning in TableLayout. :-)

Best,

Marcel

Am 21.08.2019 16:58:24 schrieb Fabio Niephaus <[hidden email]>:

On Wed, 21 Aug 2019 at 4:58 pm, Marcel Taeumel <[hidden email]> wrote:

Please find attached an updated version.

Biggest changes:

- Fixes a bug with #cellInset in TableLayout

- Adds new property #cellGap for TableLayout

+1 for calling this cellSpacing instead (similar to HTML tables).

- Uses #cellGap instead of #cellInset in most cases

Best,

Marcel

Am 14.08.2019 08:51:29 schrieb Marcel Taeumel <[hidden email]>:

Hey Chris (cmm) :-) Would you try it out on some important interactions in Maui?

Hey Tim (tpr) :-) Would you make a short performance check on a RaspberryPi?

Best,

Marcel

Am 12.08.2019 18:30:51 schrieb Marcel Taeumel <[hidden email]>:

Hi, there,

Please find attached a change set that addresses several bugs around layouting and re-drawing. I had the following goals:

- Better support for TextMorphs in TableLayout

- Better support for protruding submorphs in a non-clipping and non-shrink-wrapping morph

- Ensure full layout computation after calling #fullBounds ... no extra re-draw cycles to avoid flickering.

I have to admit that I did break some layout things back in 2016 because I didn't understand the implementation good enough. Other things have never been working correctly before, such as height-for-width updates for TextMorph children ... which do their own (text) layout and thus misbehaved in a table-layout container.

What's (still) not working?

- Useful minimum extent for windows and dialogs

- #justified list-centering with #spaceFill children (-> might be a new issue but rare?)

How can you test some changes? Well, try resizing the find-class or save-file dialog to this:

Usually, submorphs are either not protruding their morphs or they get clipped. If they are protruding and not clipped, the layout-cell computation was a mix of bounds and fullBounds. I suppose that other frameworks use just the bounds, ignoring any protruding submorphs, like this:

The blue-filled morphs are shrink-wrapped in a container arranged from the left to the right. Protruding submorphs share the owner's border color. Only the rightmost morph has its own table layout and adjuts its height to its children -- but not its width.

Best,

Marcel