On 7 November 2010 21:17, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

2010/11/7 Igor Stasenko <siguctua@gmail.com>:

...

...

Talking about complexity, let's take for example, morph layout. This is started with #doLayoutIn: in Pharo and #doLayoutIfNeeded in SimpleMorphic.

In Pharo, this method calls #adjustLayoutBounds: (19), #layout:in: (149), #layoutProportionallyIn: (10), #computeCellArrangement:in:horizontal:target: (87), #computeGlobalCellArrangement:in:horizontal:wrap:spacing: (31), #computeCellSizes:in:horizontal: (30), #computeExtraSpacing:in:horizontal:target: (136), #layoutLeftToRight:in: (91), #layoutTopToBottom:in: (91), #placeCells:in:horizontal:target: (70). The numbers in parenthesis are the sum of the lines of code of the implementors. Total lines of code for layout (taking only these most important methods) is 714. I doubt there are many people who really understand all of this code.

In SimpleMorphic (Cuis), this calls #layoutSubmorphsIn: (10), #applyLayoutFrameIn: (11), #layout:in: (24). Total lines of code is 45. I believe any smalltalker could understand these in just minutes.

Indeed, a morphic layout logic always felt overly complicated to me. It hard, because you don't know, if you can remove/replace anything from there and still have a working code. Good to see that you have managed to deal with that.

The question that immediately arises from such complexity is : - what are the features we want to implement ?

If we are not able to provide an answer, that means we can't even write tests, and that also means we can't modify/refactor the code. In such case, we tend to write more code outside existing one and so doing are just making things worse (more code more complexity).

I suspect (but I did not check) that Juan's work in Cuis is the best thing to do in such case. While at it, we should also write tests now that we have testable features.

it is hard to say, what layout policies we may need, and what can be removed/simplified. What i feel wrong with scheme, that from message names it feels like a container morph is responsible for layout, while i think, that it is submorph(s) themselves should be responsible and know how to place them within parent morph.

Nicolas

-- Best regards, Igor Stasenko AKA sig.

On 7 November 2010 22:38, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:

Sig,

I disagree; the layout policy should arrange the morphs it controls.  To do otherwise demands that the morphs be able to cope with any type of layout one might want.  The various algorithms have to go somewhere; they might as well go in the layouts.

Some layouts, like table, indeed requiring a cooperation between container morph and its submorphs. But still, i think that it should be based on a simple things: - morph should have a single layout command: lay within certain bounds. It doesn't matters where these bounds came from or how they are calculated. Then child morph could decide for itself how to lay within given bounds (like fill whole area or align to botton or top etc etc), and avoid querying parent morph or layout policy/whatever to determine own bounds, unless, of course it also having submorphs and own layout policy. So, if parent morph having no layout policy, it will simply pass its own bounds to submoprhs. And if parent having , say table layout policy, then it will calculate table cells and pass each cell bounds to each submorph for given cell. and yes, implementing this stuff is always harder than just talking about it :)

Bill

________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Sunday, November 07, 2010 2:50 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About SimpleMorphic

it is hard to say, what layout policies we may need, and what can be removed/simplified. What i feel wrong with scheme, that from message names it feels like a container morph is responsible for layout, while i think, that it is submorph(s) themselves should be responsible and know how to place them within parent morph.

-- Best regards, Igor Stasenko AKA sig.

Hi Juan, i have a couple of questions regarding the new Cuis layout, which by the way , is a much cleaner implementation!. "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. 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. 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

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

Hi Fernando, Fernando Olivero wrote:

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.

Thanks!

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?

That would be an interesting experiment. I guess these non-morph object in the morph / submorphs tree will need to support many messages of the Morph protocol. I guess someone needs to do it and see if the results are good. Go for 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.

You already did non-morph objects in the submorph tree? How was the result? Do you like it? Can we see the code?

Fernando pd: i couldnt go to Smalltalks this year, so sadly i wont see you next talk on Morphic3.0?

Well, I'm not giving a talk this year, so at least you're not missing that :(

I will continue to play with you layout morphs, and possibly adapt them to Pharo. Fernando

Great! Cheers, Juan Vuletich