A LayoutPolicy for non-formulaic layouts

Currently there are three morphic layout polices; TableLayout, ProportionalLayout and nil. Table & Proportional do formula based laying out and nil just leaves each morph where its position put it.

For various reasons I need a policy that can be more morph specific, without wanting to go overboard with sophisticated gew-gaws. So I implemented (well honestly it’s a bit of a stretch to call a subclass with one method implementing, but there y’go) ‘DelegatedLayout’ which is a singleton class that just passes the #layout:in: message off to the morph that is the first argument by sending it  #fixUpLayoutIn: {the second argument}. My morphs (that need this policy) then just implement #layoutPolicy to return `DelegatedLayout new`, which returns the singleton instance. After that, they are integrated into the whole #fullBounds/#doLayoutIn: system of updating. I’ve had so very much fun debugging the side-effects of this change, finding an amazing number of recursions and other semantic infelicities.

One could of course go for a parameterised version where the selector is set by the user but I think that may be going too far.

If anyone is interested in the idea I’m happy to stick it into the general trunk but I thought I’d
a) see if it has any attraction
b) see if anyone has clever improvements
before just doing it.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DST: Deadlock System Tables

It sounds like a good candidate for the Inbox, so we can get a better
understanding of our interest.

On Wed, Mar 12, 2014 at 7:56 PM, tim Rowledge <[hidden email]> 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. :)

Best,
Marcel

On 14-03-2014, at 9:29 AM, Marcel Taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Watch out for off-by-one errorss.