- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Making layouts using anchors

by Fernando Olivero

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. 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. Fernando On Fri, Apr 8, 2011 at 9:13 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 8 April 2011 08:51, Fernando Olivero <fernando.olivero(a)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(a)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. >

April 8, 2011

Re: [Pharo-project] A step toward reducing complexity

by Tudor Girba

Hi, Hi, On 8 Apr 2011, at 09:01, StÃ©phane Ducasse wrote: > Tudor > > is it for pharo? I do not know because I do not understand what the process is anymore. I tried to get a process going in which the design of UI goes through the same rigor and integration like the object-oriented design, but it did not work yet :(. We need a project. I proposed to do this in the context of the The Glamorous Toolkit project and to integrate all these concerns, including the UI look and feel. I would offer to lead this. Right now, everyone is still pretty much working on UI by looking at smaller pieces in his own corner. That is not bad, but it is not enough. >> Hi, >> >> I refactored the GLMUITheme to inherit from UITheme. I followed your steps and fixed a number of other issues. > > like what? Like small graphical issues related to the fact that GLMUITheme does no longer inherit all the helpers and effects from Watery2. At the moment, I basically copied some of these from Watery2 (like the management of the close/minimize/maximize) buttons. Cheers, Doru > >> There are still a couple of places to fix (like a remaining orange highlight of the text area), but it is pretty much working. -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

April 8, 2011

Re: [Pharo-project] Making layouts using anchors

by Igor Stasenko

On 8 April 2011 08:51, Fernando Olivero <fernando.olivero(a)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(a)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.

April 8, 2011

[Pharo-project] Issue 3973 in pharo: remove TextStyleFontSelectorDialogWindow

by pharo＠googlecode.com

Status: Accepted Owner: laurent....(a)gmail.com CC: marcus.d...(a)gmail.com New issue 3973 by laurent....(a)gmail.com: remove TextStyleFontSelectorDialogWindow http://code.google.com/p/pharo/issues/detail?id=3973 >> TextStyleFontSelectorDialogWindow new => error. >> Is it used ?? If it is broken, it is not used. >> Should we remove it ? things that nobody cares about should be removed. Who will maintain them? Nobody. (I will remove it on next COTDC integration - Laurent)

April 8, 2011

Re: [Pharo-project] A step toward reducing complexity

by StÃ©phane Ducasse

Tudor is it for pharo? > Hi, > > I refactored the GLMUITheme to inherit from UITheme. I followed your steps and fixed a number of other issues. like what? > There are still a couple of places to fix (like a remaining orange highlight of the text area), but it is pretty much working. > >

April 8, 2011

[Pharo-project] Issue 3972 in pharo: MenuMorph creation should be done through UIManager.

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3972 by stephane...(a)gmail.com: MenuMorph creation should be done through UIManager. http://code.google.com/p/pharo/issues/detail?id=3972 UIManager current newMenuIn: aThemedMorph for: aModel

April 8, 2011

Re: [Pharo-project] Issue 3965 in pharo: Turn off Smart Characters in Full Image by default

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3965 by marcus.d...(a)gmail.com: Turn off Smart Characters in Full Image by default http://code.google.com/p/pharo/issues/detail?id=3965 maybe not... lets see how many people will complain

April 8, 2011

Re: [Pharo-project] Issue 3842 in pharo: 1.2 Config needs to load latest code from OB Repository

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #5 on issue 3842 by marcus.d...(a)gmail.com: 1.2 Config needs to load latest code from OB Repository http://code.google.com/p/pharo/issues/detail?id=3842 TODO: update Configuration based on the latest packages <https://github.com/renggli/builder/blob/master/scripts/omnibrowser.st> (It should be noted that this is only possible after 1.2 was released. Before, the latest packages where compatible to 1.1...)

April 8, 2011

Re: [Pharo-project] Making layouts using anchors

by Fernando Olivero

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 On Thu, Apr 7, 2011 at 8:45 PM, Igor Stasenko <siguctua(a)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. >

April 8, 2011

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 3842 Comment #16 on issue 3754 by marcus.d...(a)gmail.com: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 (No comment was entered for this change.)

April 8, 2011