[squeak-dev] [Please Review] Many fixes for Morphic's layout

karl ramberg karlramberg at gmail.com
Thu Aug 22 16:55:40 UTC 2019


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 at 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 at 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 at 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 at fniephaus.com>:
>
>
> On Wed, 21 Aug 2019 at 4:58 pm, Marcel Taeumel <marcel.taeumel at 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 at 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 at 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
>>
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190822/b443812e/attachment.html>


More information about the Squeak-dev mailing list