thanks alexandre On 7 Apr 2011, at 15:37, Igor Stasenko wrote:

On 7 April 2011 22:11, Alexandre Bergel <alexandre.bergel@me.com> wrote:

...

A screenshot ?

here

...

Alexandre

-- Best regards, Igor Stasenko AKA sig. <foo.png>

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 8 April 2011 08:51, Fernando Olivero <fernando.olivero@usi.ch> wrote:

The idea is simple yet powerful, i'm favor. Can they be somehow integrated into the current layout mechanism? LayoutPolicy subclass: #AnchorPolicy Then they are just another option, and the merge could be transparent. I could add them in the context of SMx. Fernando

I don't think so. The layout policies usually is about positioning submorphs while anchors is about placing the morph itself. You can, actually, maintain layout policy by setting anchors to submorphs.

On Thu, Apr 7, 2011 at 8:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

Hi,

i hacked morphs a bit to use anchors for laying out the morphs.

The idea that you can force morph to make one of its edges (left, top, bottom, right) be dependent from other morph's edge.

Here an example:

| window morph morph2 |

window := StandardWindow labelled: 'foo'. window color: Color red. morph := Morph new.

morph anchorLeft: window leftAnchor + (window widthAnchor * 0.5) - 20. morph anchorRight: window leftAnchor + (window widthAnchor * 0.5) + 20. morph anchorTop: window topAnchor + 20. morph anchorBottom: window bottomAnchor - 20.

morph2 := Morph new. morph2 color: Color green.

morph2 anchorLeft: morph rightAnchor + 10. morph2 anchorRight: morph rightAnchor + 50. morph2 anchorTop: window topAnchor + 20. morph2 anchorBottom: window bottomAnchor - 20.

window addMorph: morph2. window addMorph: morph.

window openInWorld.

window extent: 200@200.

You can of course implement same layout using proportional layouts i.e. you can do

window addMorph: fullFrame: ...

but note that while its okay for first morph you add , a morph2 left edge is actually depending on first morph right edge. So, if it will be resized by other means (like stretched by inner morph), you won't be able to align sibling accordingly, and then you are forced to use table layout or something else.

What i like about anchors that it reflects the natural way of thinking of UI designer i.e. : "I want this morph to align to window right edge" or "I want this morph to align to previous morph right edge with 10 pixels offset"

For example, if i have two morphs, left and right, and i want to put my morph in the middle of them to fill the space between them, i can simply do:

middle := Morph new.

middle anchorLeft: leftMorph rightAnchor + 10. middle anchorRight: rightMorph leftAnchor - 10.

so, you will get a following layout:

[leftMorph] [ 10 pixels ] [ ... middle morph ..... ] [ 10 pixels ] [right morph ]

with just two lines of code!

P.S. Of course , anchors are in conflict with layouts, because you cannot have both. But some combination of them could still be used.

-- Best regards, Igor Stasenko AKA sig.

-- Best regards, Igor Stasenko AKA sig.

On 8 April 2011 09:41, Fernando Olivero <fernando.olivero@usi.ch> wrote:

In the current LayoutPolicy scheme there's no knowledge between the brothers, for the anchors this would present a potential problem.

What about moving this dependency to the parent, which knows all the morphs, instead of introducing this knowledge in the brothers?

In your example: window anchorMorph: morph at: left window anchorMorph: morph2 rightTo: morph.

Well, in the above you expressed same relationship just using different terms. You still want morph2 to align to right edge of morph. And for you, as a UI designer, it doesn't really matters where framework keeps this information - in parent morph or in morph itself. You just want morphs to obey specified rules, right?

Then  it would be transparent to the current LayoutPolicy scheme, and IMO the responsibilities are better distributed. Eliminating the knowledge between brothers greatly simplifies the UI framework.

You can't eliminate such knowledge, otherwise you won't be able to maintain such kind of relationship between morphs. You may encode it using different means, but still as i said, if you want such kind of relationship, then you have to put this dependency "knowledge" somewhere. I prefer that morph controlling own layout by himself (parent could instruct child morph to follow specific layout, but the final decision where to put itself should be up to morph iself). Because, for example, if you let parent to control the bounds of its child morphs, then you have a problem. Suppose that you have a string morph, which knows that he has fixed width and height, but its positioning could be arbitrary. So, you setting either right or left anchor: stringMorph anchorLeft: window leftAnchor. or stringMorph anchorRight: window rightAnchor. but not both, because morph could calculate the opposite edge based on its own width. Or, maybe you could do that.. You could set things up like following: | leftAnchor | leftAnchor := window leftAnchor + 10. stringMorph anchorLeft: leftAnchor. stringMorph anchorRight: leftAnchor + stringMorph widthAnchor then in this case, a position of morph is controlled by its parent, while width is maintained by himself. (a morphs which know that they having rigid width or height properties, could simply override widthAnchor/heightAnchor and maintain own constraints in this way).

Fernando

-- Best regards, Igor Stasenko AKA sig.