- Pharo-dev - lists.pharo.org

Re: [Pharo-project] collapsing panes

by Gary Chambers

Hi Doru, The weight should be applied to the expanders themselves... ex1 := (UITheme builder newExpander: 'Red' for: morph1) spaceFillWeight: 1; expanded: true. ex2 := (UITheme builder newExpander: 'Blue' for: morph2) spaceFillWeight: 2; expanded: true. ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) spaceFillWeight: 3; expanded: true. Regards, Gary ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, January 24, 2011 9:14 PM Subject: Re: [Pharo-project] collapsing panes Hi Gary, On 24 Jan 2011, at 16:16, Gary Chambers wrote: > Hi, > I don't think the layouts can be merged, as such, as they have very > different > approaches. > > With the TableLayout, it is possible to assign "weights" to each spaceFill > section to get what you want, I think. (see #spaceFillWeight:) I tried to use it, but I get no effect when I use it in your example. Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am I doing wrong? | container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2| morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red)) hResizing: #spaceFill; vResizing: #spaceFill. morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue)) hResizing: #spaceFill; vResizing: #spaceFill; spaceFillWeight: 10. morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow)) hResizing: #spaceFill; vResizing: #spaceFill. ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true. ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded: true. ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded: true. sp1 := EdgeGripMorph new target: ex1; edgeName: #bottom; vResizing: #rigid; extent: 24 @ ProportionalSplitterMorph splitterWidth; on: #mouseDown send: #expandedSizingRigid to: ex1. sp2 := EdgeGripMorph new target: ex2; edgeName: #bottom; vResizing: #rigid; extent: 24 @ ProportionalSplitterMorph splitterWidth; on: #mouseDown send: #expandedSizingRigid to: ex2. container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}. container cellInset: 0. container extent: 400@400. container openInWindow. Cheers, Doru > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, January 24, 2011 2:32 PM > Subject: Re: [Pharo-project] collapsing panes > > > Thanks a lot, Gary! I gave it a try and it does go in the wanted > direction. > > Now, the next question. I see that you are using a TableLayout. Is there a > way to specify a proportion (like in the proportional layout?) for the > initial extent of the inner panes? > > If yes, then I suppose we could merge the two layouts into one. > > Cheers, > Doru > > > On 24 Jan 2011, at 14:51, Benjamin wrote: > >> I love that :) >> It could be very useful ^^ >> >> >> Ben >> >> On Jan 24, 2011, at 2:36 PM, Gary Chambers wrote: >> >>> Tricky... >>> Just an experiment, but try the following after filing in attached >>> change set. >>> Can make the re-proportioning explicit and maybe fix things to constrain >>> to >>> the owner morph if interested... >>> >>> >>> | container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2| >>> morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red)) >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue)) >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color >>> yellow)) >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> ex1 := (UITheme builder newExpander: 'Red' for: morph1) >>> expanded: true. >>> ex2 := (UITheme builder newExpander: 'Blue' for: morph2) >>> expanded: true. >>> ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) >>> expanded: true. >>> sp1 := EdgeGripMorph new >>> target: ex1; >>> edgeName: #bottom; >>> vResizing: #rigid; >>> extent: 24 @ ProportionalSplitterMorph splitterWidth; >>> on: #mouseDown send: #expandedSizingRigid to: ex1. >>> sp2 := EdgeGripMorph new >>> target: ex2; >>> edgeName: #bottom; >>> vResizing: #rigid; >>> extent: 24 @ ProportionalSplitterMorph splitterWidth; >>> on: #mouseDown send: #expandedSizingRigid to: ex2. >>> container := UITheme builder newColumn: { >>> ex1. >>> sp1. >>> ex2. >>> sp2. >>> ex3}. >>> container cellInset: 0. >>> container extent: 400@400. >>> container openInWindow. >>> >>> >>> >>> Have a play/fun. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >>> To: "Pharo-project(a)lists.gforge.inria.fr Development" >>> <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Friday, January 21, 2011 11:18 PM >>> Subject: [Pharo-project] collapsing panes >>> >>> >>> Hi, >>> >>> I have a question about how to obtain an effect similar to minimizing a >>> pane in Eclipse. Let's consider the example from below. I have a >>> ProportionalLayout because I want to fill the entire space and be able >>> to resize the inside panes. Now, I would also like to have some way of >>> collapsing one of the panes and have the rest resize to fill the rest of >>> the space. It's a bit like I would need some part of a behavior from the >>> TableLayout. >>> >>> Can anyone provide me with some hints in this direction? Do I need to >>> create a new Layout? >>> >>> | container morph1 morph2 morph3 window | >>> container := PanelMorph new. >>> morph1 := PanelMorph new fillStyle: (SolidFillStyle color: Color red). >>> morph2 := PanelMorph new fillStyle: (SolidFillStyle color: Color blue). >>> morph3 := PanelMorph new fillStyle: (SolidFillStyle color: Color >>> yellow). >>> container changeProportionalLayout. >>> container addMorph: morph1 fullFrame: (LayoutFrame fractions: (0 @ 0 >>> corner: 1 @ 0.33)). >>> container addMorph: morph2 fullFrame: (LayoutFrame fractions: (0 @ 0.33 >>> corner: 1 @ 0.66)). >>> container addMorph: morph3 fullFrame: (LayoutFrame fractions: (0 @ 0.66 >>> corner: 1 @ 1)). >>> container addPaneSplitters. >>> container fillStyle: (SolidFillStyle color: Color yellow). >>> container extent: 400@400. >>> container openInWindow. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Be rather willing to give than demanding to get." >>> >>> >>> >>> <ExpanderTweak.1.cs> >> >> > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is > the right one." > > > > > -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Jan. 25, 2011

Re: [Pharo-project] What about a little rename in MouseEvent?

by Geert Claes

Lukas Renggli wrote: > > ... > AFAIK, most operating systems number the mouse buttons. > > - The primary button is what you use to perform actions (typically left > mouse button). > - The secondary buttons is what you use to open context menu (typically > right mouse button). > - The third button is the middle button, the fourth button, ... > > Now I see that numbers are not that far from colors, but at least they > have a logical order. I don't like #select, #menu, #extra because I does > not make sense in any other context (for example games, or touch > applications) than a traditional GUI. > Agree, on one side there are the physical buttons (button 1, 2, 3 etc) and on the other hand there are the events they trigger. e.g. for right-handed people button 1 would be the primary button where for left-handed this could very well be button 3. Then again, maybe it is time to look a bit further as it looks like the near future is heading towards a world without any physical buttons where there is no need to number or name buttons at all :) http://www.geek.com/articles/gadgets/new-apple-patent-puts-a-display-on-the… Additional gesture events: http://www.youtube.com/watch?v=JKlkte1aOOw -- View this message in context: http://forum.world.st/What-about-a-little-rename-in-MouseEvent-tp3233363p32… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2011

Re: [Pharo-project] Hapao for Test coverage!

by Vanessa PeÃ±a

Thank you very much for your help :) On Mon, Jan 24, 2011 at 10:26 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > This is cool to have news! > Excellent idea. > I will try to help you to post regularly. > > > On Jan 24, 2011, at 11:01 AM, Marcus Denker wrote: > > > On Thu, Jan 20, 2011 at 6:41 PM, Vanessa PeÃ±a <vane.c.pena(a)gmail.com> > wrote: > >> Hello all, > >> > >> We are happy to introduce you Hapao, an innovative test coverage tool > which > >> gives you an intuitive graphical representation to visually assess the > >> quality of the coverage. > >> > >> For more information and download you can visit us at: > >> http://hapao.dcc.uchile.cl/ > >> Of course, all feedback is always welcome :) > >> > > Very nice! > > > > One small thing: the dialog selecting the packages at the beginning > should > > label the button "continue"", not "terminate" (which sounds like cancel > to me). > > > > I added a blog post: http://pharo-project.org/news > > > > > > -- > > Marcus Denker -- denker(a)acm.org > > http://www.marcusdenker.de > > > > >

Jan. 25, 2011

Re: [Pharo-project] Issue 2360 in pharo: [Failing Test] nil out locals in a block if readBeforeWritten

by pharo＠googlecode.com

Updates: Summary: [Failing Test] nil out locals in a block if readBeforeWritten Comment #12 on issue 2360 by marcus.d...(a)gmail.com: [Failing Test] nil out locals in a block if readBeforeWritten http://code.google.com/p/pharo/issues/detail?id=2360 (No comment was entered for this change.)

Jan. 25, 2011

Re: [Pharo-project] Issue 3513 in pharo: Failing Test:ClosureTests.testWhileWithTempIsNil

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 2360 Comment #5 on issue 3513 by marcus.d...(a)gmail.com: Failing Test:ClosureTests.testWhileWithTempIsNil http://code.google.com/p/pharo/issues/detail?id=3513 (No comment was entered for this change.)

Jan. 25, 2011

Re: [Pharo-project] [Pharo-users] Infinite loop is not stopped by Cmd+.

by Henrik Sperre Johansen

On 24.01.2011 23:34, Mariano Martinez Peck wrote: > I could reproduce it. > Myabe I am saying something stupid, but didn't Cmd+. depends on the > process priority? > I mean, if the loop was caused by a Process with higher priority than > Cmd+. then it cannot be interrupted. > > can someone help? > > cheers > > mariano InputFetcher runs at 60, UI at 40. Only if infinite loop was in process with pri >= 60 should this possibly happen. It works on windows in 1.1.1 and 1.2core, which platform did you test on? Cheers, Henry

Jan. 25, 2011

[Pharo-project] [update 1.2] #12321

by Marcus Denker

12321 ----- Issue 3513: Failing Test:ClosureTests.testWhileWithTempIsNil (workaround, moved to 1.3) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 25, 2011

Re: [Pharo-project] Issue 2360 in pharo: nil out locals in a block if readBeforeWritten

by pharo＠googlecode.com

Comment #11 on issue 2360 by marcus.d...(a)gmail.com: nil out locals in a block if readBeforeWritten http://code.google.com/p/pharo/issues/detail?id=2360 Issue 3513 has been merged into this issue.

Jan. 25, 2011

Re: [Pharo-project] Issue 3513 in pharo: Failing Test:ClosureTests.testWhileWithTempIsNil

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.2 Comment #4 on issue 3513 by marcus.d...(a)gmail.com: Failing Test:ClosureTests.testWhileWithTempIsNil http://code.google.com/p/pharo/issues/detail?id=3513 (No comment was entered for this change.)

Jan. 25, 2011

Re: [Pharo-project] Issue 3051 in pharo: ContextPart>>objectSize

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.3 Comment #2 on issue 3051 by marcus.d...(a)gmail.com: ContextPart>>objectSize http://code.google.com/p/pharo/issues/detail?id=3051 (No comment was entered for this change.)

Jan. 25, 2011