Hmmm.... Every morph can have its own layout. In the process of layouting,
the policy gets the chance to access all morph properties in the call
#layout:in:. As far as I understand this framework, it can be *very*
morph-specific as we see with the morph flags #hResizing, #vResizing,
#disableTableLayout, ...

In your case, as far as I understood it, just give all your morphs this
singleton policy. Where is the problem? Do you want to propagate this layout
automatically to all morphs in a submorph hierarchy?

I think that your way of delegating the layout-call from the policy to the
morph breaks several assumptions about #fullBounds and #doLayoutIn:. Anyway,
you need to be sure to not trigger a layout update of the morph whose
submorphs you are currently layouting in the call. :) I feel that your need
has to be addressed somehow differently.

Note: In my projects, I implemented parts of the TableLayout policy again in
some less flexible way to avoid several problems that TableLayouts have. If,
for example, I only want to layout things vertically, I subclass a
VerticalLayout and just put those morphs in a column. Faster and less buggy
than TableLayout. TableLayout needs way more testing and fixing. :)

Best,
Marcel



--
View this message in context: http://forum.world.st/A-LayoutPolicy-for-non-formulaic-layouts-tp4748906p4749188.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.