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
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 marcel.taeumel@hpi.de: 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.
Biggest changes: - Fixes a bug with #cellInset in TableLayout - Adds new property #cellGap for TableLayout - Uses #cellGap instead of #cellInset in most cases
Best, Marcel Am 14.08.2019 08:51:29 schrieb Marcel Taeumel marcel.taeumel@hpi.de: 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 marcel.taeumel@hpi.de: 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
On Wed, 21 Aug 2019 at 4:58 pm, Marcel Taeumel marcel.taeumel@hpi.de 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 marcel.taeumel@hpi.de: 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 marcel.taeumel@hpi.de: 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. :-)
Best, Marcel Am 21.08.2019 16:58:24 schrieb Fabio Niephaus lists@fniephaus.com:
On Wed, 21 Aug 2019 at 4:58 pm, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> 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 <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: 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 <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: 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
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 marcel.taeumel@hpi.de: 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 lists@fniephaus.com:
On Wed, 21 Aug 2019 at 4:58 pm, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> 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 <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: 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 <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: 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.
Note that we plan to finally add some tests for TableLayout. ;-)
Best, Marcel Am 22.08.2019 08:33:38 schrieb Marcel Taeumel marcel.taeumel@hpi.de: 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 marcel.taeumel@hpi.de: 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 lists@fniephaus.com:
On Wed, 21 Aug 2019 at 4:58 pm, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> 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 <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: 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 <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: 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
Great to see fixes to the layout stuff :-) There were some hard to debug glitches there that I hope you get rid of.
Best, Karl
On Thu, Aug 22, 2019 at 3:32 PM Marcel Taeumel marcel.taeumel@hpi.de wrote:
I just merged the changes into Trunk. Keep me updated about any upcoming issues.
Note that we plan to finally add some tests for TableLayout. ;-)
Best, Marcel
Am 22.08.2019 08:33:38 schrieb Marcel Taeumel marcel.taeumel@hpi.de: 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 marcel.taeumel@hpi.de: 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 lists@fniephaus.com:
On Wed, 21 Aug 2019 at 4:58 pm, Marcel Taeumel marcel.taeumel@hpi.de 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 marcel.taeumel@hpi.de: 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 marcel.taeumel@hpi.de: 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
squeak-dev@lists.squeakfoundation.org
-
Fabio Niephaus -
karl ramberg -
Marcel Taeumel