I just ran the examples, and just can say...NICE!! m := LayoutMorph example3 m width: 400. m width: 600. row := m submorphs anyOne. row submorphs last delete. row delete. m delete. I've just added these lines to the example. You can find the minor changes in the attached changeset. AH! i've misread the submorph of LayoutMorph part. Still i think that LayoutMorph does not necessarily have to be a Morph, because it only has the responsibility of laying out a group of "rectangles" right? My comments were in this direction, to decouple LayoutMorph from Morph. I couldn't tell if Brazil's Area is a "Brazil visual", but i ask why not decuple it? When i did my own GauchoLayouts i've implemented like this, but now i would like ditch them and use your classes and merge them with Morph. Fernando pd: i couldnt go to Smalltalks this year, so sadly i wont see you next talk on Morphic3.0? I will continue to play with you layout morphs, and possibly adapt them to Pharo. Fernando On Tue, Nov 9, 2010 at 4:58 PM, Juan Vuletich <juan@jvuletich.org> wrote:
Hi Fernando,
Fernando Olivero wrote:
Hi Juan, i have a couple of questions regarding the new Cuis layout, which by the way , is a much cleaner implementation!.
Good! Did you play a bit with the examples in LayoutMorph class methods? They are kinda cool. For instance, do LayoutMorph example3, enlarge the morph and remove some of the submorphs, and see how the layout adjust itself.
"LayoutSpecs are the basis for a new layout mechanism, alternative to LayoutFrame. Any Morph can be given a LayoutSpec, but in order to honor it, the morph must be submorph of a LayoutMorph."
In my opinion, we dont need to enforce the LayoutMorph subclasification.
Well, I guess you misread. I didn't say 'subclass of LayoutMorph'. I said 'submorph of a LayoutMorph' :)
Because Morph>>doLayoutIfNeeded could use its "layoutMorphSpec" collaborator, if present.
doLayoutIfNeeded    ...    [self layoutSpec layoutSubmorphsIn: self layoutBounds] on: Error do: [ :ex |     ... What do you think?
Fernando
pd: Similar to decoupling the "visual layout properties" that Brazil is doing.
Well, LayoutSpec is quite like what Brazil does. For example, from the Brazil description: "When the same visual is a child of a Row, the area is an instance of a different class whose attributes and behavior are meaningful for a row cell." Looks like the main difference is that I merged the Row object and the Area object in the LayoutMorph object.
Cheers, Juan Vuletich Ps. Do you happen to be in Buenos Aires these days? We'd meet!
On Mon, Nov 8, 2010 at 3:05 PM, Juan Vuletich <juan@jvuletich.org> wrote:
Hi Folks,
WRT Layout APIs, SimpleMorphic includes the same simplified version of LayoutFrame as Cuis.
Cuis also includes a new approach, implemented in LayoutSpec and LayoutMorph. I did this for an application that requies adding new widgets without specifying a new layout for all of them. It is also nicer than LayoutFrame, and will replace it at some moment. But it is not used at all by SimpleMorphic or Cuis, and that's why I did not include it in SimpleMorphic for Pharo. But you might open Cuis and take a look it, and load it in Pharo if you like. Try the example class methods in LayoutMorph, and resize the morph to see what it can do.
Cheers, Juan Vuletich
------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.864 / Virus Database: 271.1.1/3246 - Release Date: 11/09/10 04:34:00