The Layout Resize Problem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

The Layout Resize Problem

KenDickey
Greetings,

I have been thinking about "the layout resize problem".

The basis of the layout resize problem is that when someone changes fonts, we would like windows/panes/labels to adjust themselves with the minimum of fuss.

Also, when I resize a Morph I sometimes find that the layouts shrink below submorph containment size.  Currently, specifying a LayoutSpec which indicates "resize, but use morph extent as a minimum" seems awkward.

My intuitive thought is to make use of Morph>>minimumExtent.  LayoutMorphs (composts) could use the maximum width (mimimumExtent x) of their submorphs and the sum of the morph heights (minimumExtent y), possibly adding an extentBorder, and use this as its minimumExtent.

Note that if no submorph changes size, this value can be cached as it does not have to be recalculated.  Low cost calculations (buttonExtent, measureContents) don't have to be cached.

This leads to two questions:
 [1] How to be informed when something changes that one depends on to calculate ones size.
 [2] How, when something changes size, to do this once for each affected morph?

My thought here is that the World could be informed that font size (or whatever influences  size calculations) changes.  Then it asks each of its submorphs, recursively, to recalculateMinimumExtent and layoutSubmorphs.  

This should happen top to bottom once for each resize causing event.

We can update our size calculating code and get rid of "Please Close All Open Windows".

Does this sound about right?  Other strategies?

Cheers,
-KenD

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD