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 <[email protected]> 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 <[email protected]> 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 >>> >>> > > >
LayoutMorph examples.1.cs
Description: Binary data
