February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] MVP: quite interesting.

by Krishsmalltalk

Should read Martin fowler blog on this for a simpler explanation http://martinfowler.com/eaaDev/uiArchs.html http://martinfowler.com/eaaDev/ModelViewPresenter.html Sudhakar krishnamachari Extn 91-40403012 Cell 9902104814 On Feb 4, 2012, at 10:07 PM, Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch> wrote: > I tried t follow MVP idea, but not sure I got it right. > > Hilaire > > Le 04/02/2012 12:43, Benjamin a Ã©crit : >> >> On Nov 17, 2011, at 10:49 PM, StÃ©phane Ducasse wrote: >> >>> http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/ModelViewPre… >>> >>> Stef >> >> >> > > > -- > Dr. Geo -- http://www.drgeo.eu > >

Feb. 5, 2012

Re: [Pharo-project] MVP

by Schwab,Wilhelm K

More: proportional layouts need to let each view have a proportion (zero makes it fixed size) and splitters should be just another view that is added to a composite, following the horizontal/vertical nature of the layout manager. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Saturday, February 04, 2012 9:25 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] MVP I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. Sleep calls... Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Saturday, February 04, 2012 6:36 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] MVP Hello all, I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. Bill

Feb. 5, 2012

Re: [Pharo-project] MVP

by Schwab,Wilhelm K

I'm still a little overwhelmed, but I see attention to layout; this has been a BIG stumbling block for me in my efforts to bring MVP to Pharo. I recommend using nested composite view/presenter pairs for most layout. First, it lends itself well to an eventual view editor, and second, can be surprisingly easy to code directly. Each composite view has a layout manager. Layouts include constrained table-like elements, but the real workhorses are proportional layouts, which can be set either horizontal or vertical. By nesting them, very complicate behavior can be achieved. There, said "nesting," and that has been where I have fallen into trouble. Pharo/morphic layout works great for children of the top level, but after that, I can't get reliable results. Sleep calls... Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Saturday, February 04, 2012 6:36 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] MVP Hello all, I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. Bill

Feb. 5, 2012

[Pharo-project] MVP

by Schwab,Wilhelm K

Hello all, I have been to busy to read today, but I like seeing any discussion of MVP. I am **slowly** working on a framework for it, but would be glad to be beaten to it. Default models are key; they must be replaceable, but (sub)triads should work "out of the box." Models can include value holders, value adapters, converters, and contexts, depending on how they are wired. I have something of a start on the adapters and converters, which I can try to package and make available. If nothing else, they will have value in seeding discussion if not be directly usable. More to come. Bill

Feb. 4, 2012

[Pharo-project] [update 1.4] #14313

by StÃ©phane Ducasse

14313 ----- - Issue 5217: LanguageEnvironment should cache converters. Thanks Benjamin van ryseghem, Igor Stasenko and Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=5217 Stef

Feb. 4, 2012

[Pharo-project] May be we should remove the nepaleseEnvironment?

by StÃ©phane Ducasse

and such code ? isFontAvailable ^ (Smalltalk globals classNamed: #RomePluginCanvas) ifNil: [ false ] ifNotNil: [ :canvasClass | canvasClass pangoIsAvailable ] Stef

Feb. 4, 2012

Re: [Pharo-project] Just found a wonderful method :)

by Nicolas Cellier

Please write a SUnit Test. 2012/2/4 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: > Can't resist to share my treasure ;) > > PluggableListMorph>>#selectedMorph: aMorph > Â Â Â Â "this shouldn't be used any longer" > > Â Â Â Â "self isThisEverCalled ." > > Â Â Â Â Beeper Â beep. > Â Â Â Â true ifTrue: [^self] > > > > ;) > > Ben >

Feb. 4, 2012

Re: [Pharo-project] Trying to undeerstand Morphic subclasses and step/stepAt:

by Sean P. DeNigris

Dave Mason-3 wrote > > I wanted to make it a subclass of SystemWindow (I'd actually prefer > StandardWindow in Pharo but there doesn't appear to be an equivalent in > Squeak). But when I do, the step method doesn't get called. (Nor does > stepAt:) (And StandardWindow behaves the same.). > To get your SystemWindow subclass to step, send #startStepping. I don't know if it's any better, but when I create my own morph-in-a-window, I usually don't subclass SystemWindow, but add my morph to a window using openInWindowLabelled: or addMorph:fullFrame:. I feel like I have a little more flexibility if I later want to use it not-in-a-window. HTH, Sean -- View this message in context: http://forum.world.st/Trying-to-undeerstand-Morphic-subclasses-and-step-ste… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 4, 2012

Re: [Pharo-project] Trying to undeerstand Morphic subclasses and step/stepAt:

by Lawson English

Dave, when I create new morph classes, I usually subclass PasteUpMorph. If I need it in a window, I call #openInWindow on a new instance, though I find that first putting it in a ScrollPane makes for more useful behavior -usually. Regardless, the #step and #stepAt: calls work as expected when you use a PasteUpMorph subclass since you get the same behavior as you get from World. Lawson On 2/4/12 10:33 AM, Dave Mason wrote: > Hi, > > I want to build a morphic application (for algorithm animation) so I need to do something in the step method. > > I wanted to make it a subclass of SystemWindow (I'd actually prefer StandardWindow in Pharo but there doesn't appear to be an equivalent in Squeak). But when I do, the step method doesn't get called. (Nor does stepAt:) (And StandardWindow behaves the same.). > > But if I move it to MorphicModel step/stepAt: gets called, but I don't get any of that SystemWindow goodness. > > I've looked at the dispatch in Morph, and I don't see anything different in Worldstate>>runLocalStepMethodIn: but this stuff is very difficult to debug, because there's asynchronous stuff running behind the scenes. In particular, > lastStepMessage value: now. > lastStepMessage ifNotNil: [... > is a little weird! > > Any pointers appreciated. > > Thanks ../Dave >

Feb. 4, 2012

[Pharo-project] [update 1.4] #14312

by StÃ©phane Ducasse

14312 ----- - Issue 4602: Fixes and improvements on MC. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=4602 Stef

Feb. 4, 2012