[squeak-dev] Re: A LayoutPolicy for non-formulaic layouts

tim Rowledge tim at rowledge.org
Fri Mar 14 21:00:01 UTC 2014


On 14-03-2014, at 9:29 AM, Marcel Taeumel <marcel.taeumel at student.hpi.uni-potsdam.de> wrote:

> Hmmm.... Every morph can have its own layout.

Indeed - and nothing about a DelegatedLayout changes that. Since I know what I want my morphs to do I simply chose to explicitly return the policy instead of having an individual instance in the extension for each of hundreds of morphs. Space saving, I call it. If one wanted to use the extension, no problem.

> 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, …

And nothing changes with DelegatedLayout.

> 
> 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?

In this particular case there is no subclass related issue, so it doesn’t matter.

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

Nothing changes from any of the currently in-system layout policies. They all have to take some care with the same things. And actually, most of the time it is perfectly ok to do something that sends #layoutChanged since the fullBounds are not re-set until after the layout has completed.  However, it is indeed very easy to make complexly recursive code that causes all sorts of problems. How do we think I noticed how annoying the interrupt key code is? Oh yes, because I screwed up and made a deep recursion that I couldn’t stop.

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

Yes, that sounds like a good idea. Many TableLayouts are just rows or columns and would almost certainly better handle by an explicit kind of policy. Please submit one ;-)


> Faster and less buggy
> than TableLayout. TableLayout needs way more testing and fixing. :)

It almost certainly needs some optimisation, too.

A secondary issue I’ve noticed is that the very generic #layoutChanged notification can be a pain because you have no context about what sort of change, where. A single morph deep in a tree of morphs has a tiny change that actually won’t affect any layout at all, but the notification goes all the way to the top morph and causes a lot of work that didn’t need to be done. Some better way of handling this might speed up the UI a lot. Unless I’ve misunderstood things, which is of course always a possibility.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Watch out for off-by-one errorss.




More information about the Squeak-dev mailing list