April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3870 in pharo: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew

by pharo＠googlecode.com

Comment #3 on issue 3870 by marcus.d...(a)gmail.com: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew http://code.google.com/p/pharo/issues/detail?id=3870 I think we should deprecate ClassTestCase... at the time it looked like a nice idea, but in the meantime I got convinced that for tests, less magic is better and code duplication is not a problem. So all subclasses should just implement the handfull of tests that ClassTestCase provides themselves and we remove it.

April 8, 2011

Re: [Pharo-project] Issue 3870 in pharo: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew

by pharo＠googlecode.com

Comment #2 on issue 3870 by nicolas....(a)gmail.com: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew http://code.google.com/p/pharo/issues/detail?id=3870 But that is still not enough... #selectorsToBeIgnored is itself ignored for determining the test suite... What a mess ! It seems that other subclasses do redefine #testNew...

April 8, 2011

Re: [Pharo-project] Issue 3870 in pharo: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew

by pharo＠googlecode.com

Comment #1 on issue 3870 by nicolas....(a)gmail.com: [Failing Test] 1.3 KernelTests.Methods.CompiledMethodTest.testNew http://code.google.com/p/pharo/issues/detail?id=3870 First, there is a missing subclassResponsibility in CompiledMethodTest Fixing this is not enough... The aim of the failing test is to check (CompiledMethod new) which never worked and shouldn't IMO. So #testNew should be among #selectorsToBeIgnored

April 8, 2011

Re: [Pharo-project] Debugging Cog crash

by Mariano Martinez Peck

also...shouldn't be a crash/dump file somewhere? can you write the output of the console where you invoke the VM into a file ? (using > to redirect) Cheers Mariano On Thu, Apr 7, 2011 at 11:10 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Hello all, > > I have an account on an Ubuntu terminal server (at least I think that's > what it would be called) running 10.10. The Cog one-click image crashes > with "Segmentation fault" (if run from a terminal); the legacy VM seems to > run the image nicely on the box. Any ideas? I will happily collect any > facts that will be of help, but I need some > direction. > > Bill > > > > -- Mariano http://marianopeck.wordpress.com

April 8, 2011

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