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
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:.
Time: 19 April 2015, 11:27:22.653 am
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
> The order within the 'submorphs' collection is the same, however, the
> layering appears to be the opposite. Any ideas?
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.
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. "<--- 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
On Tue, Aug 25, 2015 at 4:48 AM, marcel.taeumel <[hidden email]> wrote:
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:
> Hi Chris,
> I could not find a place where headingMorphs is initialized in a useful way.
> Btw: You should not override MauiMorph >> minExtent: but rather
> #minimumWidth and #minimumHeight for the same effect.
> View this message in context: http://forum.world.st/What-happened-to-Morph-layering-tp4845404p4845881.html > Sent from the Squeak - Dev mailing list archive at Nabble.com.