[Please Review] Many fixes for Morphic's layout

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Please Review] Many fixes for Morphic's layout

marcel.taeumel
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









layout-fixes.8.cs (111K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Please Review] Many fixes for Morphic's layout

marcel.taeumel
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