What happened to Morph layering?

My Maui applications are suffering greatly by a change to Morphic
during the 4.6/5.0 cycle which is causing morphs to be layered in the
opposite order than they were in 4.5.  The result is, I have morphs of
a Proportional layout covering other Morphs which I need to interact
with.

The order within the 'submorphs' collection is the same, however, the
layering appears to be the opposite.  Any ideas?

Found it.  It was the removal of the call to #fullBounds (with a
"Sigh" from Andreas about it) in Morph>>#layoutProportionallyIn:.

-----------
Name: Morphic-mt.900
Author: mt
Time: 19 April 2015, 11:27:22.653 am
UUID: 950b4378-f3fe-db4c-b054-88b646a1feb0
Ancestors: Morphic-mt.899

Fix to avoid unnecessary layout computation for proportional layout.

Note: Please report any visual glitches. Not 100% sure about the
extent of this change...
-------------

I think I found a place in my app where I can send a make-up
#fullBounds to my Morph with a proportional layout.  The challenging
aspect of it is, I couldn't just send it upon creation, the morph must
be installed in the world before it can do it.  It makes sense that
Layouts have to respond dynamically to surrounding Morphs to do their
job, but the complexity can get overwhelming I've even had to put a
guard in one place to avoid endless layout feedback..

On Mon, Aug 24, 2015 at 5:00 PM, Chris Muller <[hidden email]> wrote:
> My Maui applications are suffering greatly by a change to Morphic
> during the 4.6/5.0 cycle which is causing morphs to be layered in the
> opposite order than they were in 4.5.  The result is, I have morphs of
> a Proportional layout covering other Morphs which I need to interact
> with.
>
> The order within the 'submorphs' collection is the same, however, the
> layering appears to be the opposite.  Any ideas?
>

Hi Chris,

does it affect event handling only or drawing, too?

You problem description seems to have nothing to do with proportional layouts... Especially since the submorphs collection is in correct order. Layout policies set position and extent, nothing more. :) The layering effect comes due to correct drawing and event handling according to the submorphs collection order.

Best,
Marcel

Hi Chris,

does this fix your problem?
http://forum.world.st/The-Trunk-Morphic-mt-999-mcz-td4845514.html

Best,
Marcel

Thanks Marcel, unfortunately, no, the problem I'm having has nothing
to do with SystemWindows, just plain Morphs.

I found a way you can see the problem yourself.  If you would be
willing to install the head release of Maui into a 5.0 trunk image,
and then in a workspace:

   | morph | morph := FileDirectory default entries maui.
   World doOneCycleNow.
   morph regenerateHeading.
   World doOneCycleNow.  "<--- Argh, need this 2nd one now for it to
fully update!  Why?"

If you try the above once each for the two different versions of
Morph>>#layoutProportionallyIn:, with (mt 4/19/2015 11:06), each
subsequent column header is above the one to its left, as it should
be.  However, with (mt 4/24/2015 10:11), the z-order is reversed,
causing my column sort buttons to be covered up, inaccessible for
application users.

Best,
  Chris

On Tue, Aug 25, 2015 at 4:48 AM, marcel.taeumel <[hidden email]> wrote:

I will have a look...

Btw: "ActiveWorld submorphs maui" raises an exception.

Best,
Marcel

"FileDirectory default entries maui" does also raise an exception. headingMorphs is nil in MauiCollectionMorph >> #allMauiMorphsDo:ifNotIn:

Best,
Marcel

Hi Chris,

I could not find a place where headingMorphs is initialized in a useful way. Hmmm...

Btw: You should not override MauiMorph >> minExtent: but rather #minimumWidth and #minimumHeight for the same effect.

Best,
Marcel

Rats!  The BrpExtensions package was not included in my update map, sorry!

I've just added it and retested, its working and showing the problem,
could you please try it again?

On Wed, Aug 26, 2015 at 4:55 AM, marcel.taeumel <[hidden email]> wrote:

On 25-08-15 03:12, Chris Muller wrote:
> Found it.  It was the removal of the call to #fullBounds (with a
> "Sigh" from Andreas about it) in Morph>>#layoutProportionallyIn:.

Removing that call sounds like a good idea. What was needed to make it
work? Or doesn't it? Marcel has done a lot of clean-ups AFAIK.

Stephan