On Fri, Mar 14, 2014 at 5:29 PM, Marcel Taeumel <
marcel.taeumel at student.hpi.uni-potsdam.de> wrote:

> 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. :)
>

+1

Layout is quite hard to get working right.

cheers,
Karl

>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140314/0410ab43/attachment.htm