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 ma.chris.m@gmail.com 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?
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
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
-- View this message in context: http://forum.world.st/What-happened-to-Morph-layering-tp4845404p4845449.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Hi Chris,
does this fix your problem? http://forum.world.st/The-Trunk-Morphic-mt-999-mcz-td4845514.html
Best, Marcel
-- View this message in context: http://forum.world.st/What-happened-to-Morph-layering-tp4845404p4845515.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
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 Marcel.Taeumel@hpi.de wrote:
Hi Chris,
does this fix your problem? http://forum.world.st/The-Trunk-Morphic-mt-999-mcz-td4845514.html
Best, Marcel
-- View this message in context: http://forum.world.st/What-happened-to-Morph-layering-tp4845404p4845515.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
I will have a look...
Btw: "ActiveWorld submorphs maui" raises an exception.
Best, Marcel
-- View this message in context: http://forum.world.st/What-happened-to-Morph-layering-tp4845404p4845868.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
"FileDirectory default entries maui" does also raise an exception. headingMorphs is nil in MauiCollectionMorph >> #allMauiMorphsDo:ifNotIn:
Best, Marcel
-- View this message in context: http://forum.world.st/What-happened-to-Morph-layering-tp4845404p4845870.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
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
-- 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.
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 Marcel.Taeumel@hpi.de wrote:
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
-- 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.
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
marcel.taeumel -
Stephan Eggermont