August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: Re: Squeaksource XML Parser - Enhanced support for CDATA Sections

by StÃ©phane Ducasse

> > coalesceCDATASections: aBoolean > > or > > enableCoalescing > disableCoalescing most of the time you need the 3 because the first one let you easily build scripts for me > coalesceCDATASections: aBoolean is a setter not a testing selector

Aug. 10, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

UITheme builder answers a singleton ComposableMorph so is technically reused. Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, August 10, 2010 12:05 AM Subject: Re: [Pharo-project] Early days of an MVP framework > Gary, > > I tried making some changes and found it very easy to end up with an empty > shell. It appears that you are using the builder as a factory and are > completely uninterested in hanging on to it :) Is that accurate? Is it > good design? > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Schwab,Wilhelm K > Sent: Monday, August 09, 2010 5:06 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > Gary, > > Thanks for the examples. One thing is driving me nuts: in the past, I > thought that creating a new row or column made a morph but did not add it > to the morph being created. Might I have added them redundantly? Does > re-adding a child have no effect or somehow replace it? Is this a > morphi/Polymorph beginner trap? Be honest, I can take it :) > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary > Chambers > Sent: Monday, August 09, 2010 5:45 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > And with a stack layout... > > (UITheme builder > newColumn: { > UITheme builder newTabGroup: { > 'First page' -> ((UITheme builder newStack: { > (UITheme builder > newAlphaImage: UITheme current warningIcon > help: nil) > alpha: 0.5. > CircleMorph new > hResizing: #spaceFill; > vResizing: #spaceFill}) > fillStyle: Color red; > hResizing: #spaceFill; > vResizing: #spaceFill). > 'Second page' -> (UITheme builder newPanel > fillStyle: Color green; > hResizing: #spaceFill; > vResizing: #spaceFill)}. > (UITheme builder newRow: { > UITheme builder newOKButton. > UITheme builder newCancelButton}) > listCentering: #bottomRight}) > extent: 200@300; > openInWindow > > Regards, Gary > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, August 09, 2010 11:30 AM > Subject: Re: [Pharo-project] Early days of an MVP framework > > >> This even (to get buttons on right with correct tab key navigation >> ordering... >> >> (UITheme builder >> newColumn: { >> UITheme builder newTabGroup: { >> 'First page' -> (UITheme builder newPanel >> fillStyle: Color red; >> hResizing: #spaceFill; >> vResizing: #spaceFill). >> 'Second page' -> (UITheme builder newPanel >> fillStyle: Color green; >> hResizing: #spaceFill; >> vResizing: #spaceFill)}. >> (UITheme builder newRow: { >> UITheme builder newOKButton. >> UITheme builder newCancelButton}) >> listCentering: #bottomRight}) >> extent: 200@300; >> openInWindow >> >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, August 09, 2010 11:07 AM >> Subject: Re: [Pharo-project] Early days of an MVP framework >> >> >>> Any Morph can use a layoutPolicy. >>> Available are >>> none (position based) >>> Prorportional (frame/fractions/offsets) >>> Table (overly complex too) >>> Row (one of mine, quicker for simple rows) >>> Stack (mine, overlay morphs on top of each other) >>> >>> TEasilyThemed provides some methods like... >>> >>> newRow: {aMorph, anotherMorph} >>> newColumn: >>> >>> Something like this works... >>> >>> (UITheme builder >>> newColumn: { >>> UITheme builder newPanel >>> fillStyle: Color red; >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> UITheme builder newRow: { >>> UITheme builder newOKButton. >>> UITheme builder newCancelButton}}) >>> extent: 200@300; >>> openInHand >>> >>> (can use openInWindow also)... >>> >>> Rather busy today, hope this helps in the meantime... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> >>> To: <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Sunday, August 08, 2010 11:46 PM >>> Subject: [Pharo-project] Early days of an MVP framework >>> >>> >>>> Gary, >>>> >>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt >>>> coaching), until I needed to repeat a "complex" GUI component and >>>> wanted/insisted on doing so with some reuse. Seaside gives us >>>> components on web pages; we need them for GUI code too. I tried >>>> turning my presenter-like structures into factories that would add >>>> morphs to a single shell, but it fell apart when it came time to set >>>> the framing values. I was not particularly interested in fixing it, >>>> because if I could do that, I would simply build proper composite >>>> widgets using the fix. >>>> >>>> The problem appears to be in SystemWindow, which does some >>>> incredibly complicated things, all of which (correct me if I am >>>> wrong) would be unnecessary if only there were a good set of layout >>>> managers. I can get very simple-minded about things, but it would >>>> make a whole lot more sense to me to create rows and columns of >>>> widgets, adding splitters between them until the whole things >>>> behaves as intended, rather than writing code (present only in a >>>> top-level shell) that tries to split things up into rows using its >>>> own judgment. Not good. I realize you did not create the >>>> situation, and have done wonders to make it work far better than when >>>> you found it. >>>> >>>> Some time ago, I built an emulated widget framework for Dolphin, >>>> which I needed because the combination of Dolphin's view resources >>>> and Windows itself was too slow for what I was trying to do. That >>>> project included a somewhat strange set of layout classes, but the >>>> basics are present, and it is not Object Arts' IP. I ported the >>>> classes to Pharo and did some work on stub View and Presenter >>>> classes that I had added to Pharo largely to passify my code that I >>>> was importing from Dolphin. The layouts think in terms of emulated >>>> widgets, and I see no reason to change their minds: I might want to >>>> replicate the framework. However, dynamic typing and a couple of >>>> extra methods allow them to work with just about anything. My goals >>>> are modest. Being able to compose rows and columns would do a lot >>>> for me. Add splitters and the ability to fix the size of some items, >>>> and I could almost anything I would need. >>>> >>>> View class>>example >>>> | row column dot square out shell | >>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32. >>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32. >>>> out := Array writeStream. >>>> >>>> row := ContainerView row. >>>> 2 timesRepeat:[ >>>> column := row addSubview:ContainerView column. >>>> 2 timesRepeat:[ >>>> out nextPut:( >>>> column addSubview:ImageView new >>>> ). >>>> ]. >>>> ]. >>>> >>>> out contents with:{ dot copy. square copy. square copy. dot copy. } >>>> do:[ :view :form | view morph image:form. >>>> ]. >>>> >>>> row rectangle:( 0@0 extent:400@400 ). >>>> row layout. >>>> >>>> shell := StandardWindow labelled:'Hello MVP'. >>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. >>>> >>>> >>>> The above code produces an array of dots and squares, as intended. >>>> One quirk is that the grid does not resize as the shell resizes, a >>>> consequence of my not having hooked it up to resize events. I might >>>> get some interesting meltdowns once I begin to do that =:0 I used >>>> your PanelMorph as the "view" associated with ContainerView. What, >>>> ContainView isn't a view??? No. The code is biased toward Morphic, >>>> but hopefully the same code should extend to wx, GTK, etc. >>>> Dolphin's views have a handle instance variable to control the >>>> external resource; these views have an instance variable pointing to >>>> their morph. Handling of sub views works pretty much as in Dolphin: >>>> any view/morph can have children, but adding them is "legal" only for >>>> composites. >>>> >>>> Most systems I have seen treat coordinates relative to the >>>> parent/owner, but not Morphic. I remember seeing plans to make the >>>> change, but nothing after that. The view instances provide a >>>> natural place to fix things, so I took the plunge. If we switch to >>>> some other graphical realization, we can simply remove the the >>>> transformation. >>>> >>>> Are the existing splitters as strange as SystemWindow? By that I >>>> mean, would it be reasonable to add them between other morphs and >>>> look for events from them, or will they have to be replaced? I will >>>> eventually need splitters, but I could initially live without them >>>> if I can get reliable composition where I need it. >>>> >>>> There are very few view classes at present. MorphView can wrap >>>> almost anything, so it might be better to create a rich set of >>>> presenters instead. Dolphin's view resources are going to be >>>> interesting to replace. There are some complexities that I suspect >>>> are in deference to Windows, and some that might be avoidable. For >>>> our purposes, it might be enough to use SIXX to serialize a bunch of >>>> message sends and gzip the results to save memory. Another option >>>> might be to rely on class methods; having full closures won't hurt; >>>> they might allow sufficient hooking that resources in the Dolphin sense >>>> won't even be necessary. >>>> The desire for them quickly arises because views get realized in >>>> places know nothing about how the views should be configured; at >>>> least I think that is what happened to me after just a couple of >>>> hours. I am far less interested in having a graphical view editor >>>> than I am in being able to write **GOOD** code that assembles things >>>> as I want. If the result happens to allow a graphical editor too, so >>>> much the better. >>>> >>>> Any interest? >>>> >>>> Bill >>>> >>>> >>>> ----------------------------- >>>> >>>> View >>>> MorphViev >>>> ImageView >>>> ContainerView >>>> >>>> ViewGadgetLayoutAbstract >>>> ScrollerGadgetLayout >>>> NullViewGadgetLayout >>>> FixedStretchFixedGadgetLayout >>>> ProportionalGadgetLayout >>>> PreferredExtentsGadgetLayout >>>> GridGadgetRowsLayout >>>> VerticalListLayout >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

Making a new morph doesn't necessarily add it... the helper methods from TEasilyThemed (used by ComposableMorph for instance) generally take a collection of morphs as parameter to do that for you though. Re-adding will keep the same morph but typically position it at the front or back depending on the method used (addMorph: addMorphBack: etc.). Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, August 09, 2010 11:05 PM Subject: Re: [Pharo-project] Early days of an MVP framework > Gary, > > Thanks for the examples. One thing is driving me nuts: in the past, I > thought that creating a new row or column made a morph but did not add it > to the morph being created. Might I have added them redundantly? Does > re-adding a child have no effect or somehow replace it? Is this a > morphi/Polymorph beginner trap? Be honest, I can take it :) > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary > Chambers > Sent: Monday, August 09, 2010 5:45 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > And with a stack layout... > > (UITheme builder > newColumn: { > UITheme builder newTabGroup: { > 'First page' -> ((UITheme builder newStack: { > (UITheme builder > newAlphaImage: UITheme current warningIcon > help: nil) > alpha: 0.5. > CircleMorph new > hResizing: #spaceFill; > vResizing: #spaceFill}) > fillStyle: Color red; > hResizing: #spaceFill; > vResizing: #spaceFill). > 'Second page' -> (UITheme builder newPanel > fillStyle: Color green; > hResizing: #spaceFill; > vResizing: #spaceFill)}. > (UITheme builder newRow: { > UITheme builder newOKButton. > UITheme builder newCancelButton}) > listCentering: #bottomRight}) > extent: 200@300; > openInWindow > > Regards, Gary > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, August 09, 2010 11:30 AM > Subject: Re: [Pharo-project] Early days of an MVP framework > > >> This even (to get buttons on right with correct tab key navigation >> ordering... >> >> (UITheme builder >> newColumn: { >> UITheme builder newTabGroup: { >> 'First page' -> (UITheme builder newPanel >> fillStyle: Color red; >> hResizing: #spaceFill; >> vResizing: #spaceFill). >> 'Second page' -> (UITheme builder newPanel >> fillStyle: Color green; >> hResizing: #spaceFill; >> vResizing: #spaceFill)}. >> (UITheme builder newRow: { >> UITheme builder newOKButton. >> UITheme builder newCancelButton}) >> listCentering: #bottomRight}) >> extent: 200@300; >> openInWindow >> >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, August 09, 2010 11:07 AM >> Subject: Re: [Pharo-project] Early days of an MVP framework >> >> >>> Any Morph can use a layoutPolicy. >>> Available are >>> none (position based) >>> Prorportional (frame/fractions/offsets) >>> Table (overly complex too) >>> Row (one of mine, quicker for simple rows) >>> Stack (mine, overlay morphs on top of each other) >>> >>> TEasilyThemed provides some methods like... >>> >>> newRow: {aMorph, anotherMorph} >>> newColumn: >>> >>> Something like this works... >>> >>> (UITheme builder >>> newColumn: { >>> UITheme builder newPanel >>> fillStyle: Color red; >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> UITheme builder newRow: { >>> UITheme builder newOKButton. >>> UITheme builder newCancelButton}}) >>> extent: 200@300; >>> openInHand >>> >>> (can use openInWindow also)... >>> >>> Rather busy today, hope this helps in the meantime... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> >>> To: <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Sunday, August 08, 2010 11:46 PM >>> Subject: [Pharo-project] Early days of an MVP framework >>> >>> >>>> Gary, >>>> >>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt >>>> coaching), until I needed to repeat a "complex" GUI component and >>>> wanted/insisted on doing so with some reuse. Seaside gives us >>>> components on web pages; we need them for GUI code too. I tried >>>> turning >>>> my presenter-like structures into factories that would add morphs to a >>>> single shell, but it fell apart when it came time to set the framing >>>> values. I was not particularly interested in fixing it, because if I >>>> could do that, I would simply build proper composite widgets using the >>>> fix. >>>> >>>> The problem appears to be in SystemWindow, which does some incredibly >>>> complicated things, all of which (correct me if I am wrong) would be >>>> unnecessary if only there were a good set of layout managers. I can >>>> get >>>> very simple-minded about things, but it would make a whole lot more >>>> sense to me to create rows and columns of widgets, adding splitters >>>> between them until the whole things behaves as intended, rather than >>>> writing code (present only in a top-level shell) that tries to split >>>> things up into rows using its own judgment. Not good. I realize you >>>> did not create the situation, and have done wonders to make it work far >>>> better than when you found it. >>>> >>>> Some time ago, I built an emulated widget framework for Dolphin, which >>>> I >>>> needed because the combination of Dolphin's view resources and Windows >>>> itself was too slow for what I was trying to do. That project included >>>> a somewhat strange set of layout classes, but the basics are present, >>>> and it is not Object Arts' IP. I ported the classes to Pharo and did >>>> some work on stub View and Presenter classes that I had added to Pharo >>>> largely to passify my code that I was importing from Dolphin. The >>>> layouts think in terms of emulated widgets, and I see no reason to >>>> change their minds: I might want to replicate the framework. However, >>>> dynamic typing and a couple of extra methods allow them to work with >>>> just about anything. My goals are modest. Being able to compose rows >>>> and columns would do a lot for me. Add splitters and the ability to >>>> fix >>>> the size of some items, and I could almost anything I would need. >>>> >>>> View class>>example >>>> | row column dot square out shell | >>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32. >>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32. >>>> out := Array writeStream. >>>> >>>> row := ContainerView row. >>>> 2 timesRepeat:[ >>>> column := row addSubview:ContainerView column. >>>> 2 timesRepeat:[ >>>> out nextPut:( >>>> column addSubview:ImageView new >>>> ). >>>> ]. >>>> ]. >>>> >>>> out contents with:{ dot copy. square copy. square copy. dot copy. } >>>> do:[ :view :form | >>>> view morph image:form. >>>> ]. >>>> >>>> row rectangle:( 0@0 extent:400@400 ). >>>> row layout. >>>> >>>> shell := StandardWindow labelled:'Hello MVP'. >>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. >>>> >>>> >>>> The above code produces an array of dots and squares, as intended. One >>>> quirk is that the grid does not resize as the shell resizes, a >>>> consequence of my not having hooked it up to resize events. I might >>>> get >>>> some interesting meltdowns once I begin to do that =:0 I used your >>>> PanelMorph as the "view" associated with ContainerView. What, >>>> ContainView isn't a view??? No. The code is biased toward Morphic, >>>> but >>>> hopefully the same code should extend to wx, GTK, etc. Dolphin's views >>>> have a handle instance variable to control the external resource; these >>>> views have an instance variable pointing to their morph. Handling of >>>> sub views works pretty much as in Dolphin: any view/morph can have >>>> children, but adding them is "legal" only for composites. >>>> >>>> Most systems I have seen treat coordinates relative to the >>>> parent/owner, >>>> but not Morphic. I remember seeing plans to make the change, but >>>> nothing after that. The view instances provide a natural place to fix >>>> things, so I took the plunge. If we switch to some other graphical >>>> realization, we can simply remove the the transformation. >>>> >>>> Are the existing splitters as strange as SystemWindow? By that I mean, >>>> would it be reasonable to add them between other morphs and look for >>>> events from them, or will they have to be replaced? I will eventually >>>> need splitters, but I could initially live without them if I can get >>>> reliable composition where I need it. >>>> >>>> There are very few view classes at present. MorphView can wrap almost >>>> anything, so it might be better to create a rich set of presenters >>>> instead. Dolphin's view resources are going to be interesting to >>>> replace. There are some complexities that I suspect are in deference to >>>> Windows, and some that might be avoidable. For our purposes, it might >>>> be enough to use SIXX to serialize a bunch of message sends and gzip >>>> the >>>> results to save memory. Another option might be to rely on class >>>> methods; having full closures won't hurt; they might allow sufficient >>>> hooking that resources in the Dolphin sense won't even be necessary. >>>> The desire for them quickly arises because views get realized in places >>>> know nothing about how the views should be configured; at least I think >>>> that is what happened to me after just a couple of hours. I am far >>>> less >>>> interested in having a graphical view editor than I am in being able to >>>> write **GOOD** code that assembles things as I want. If the result >>>> happens to allow a graphical editor too, so much the better. >>>> >>>> Any interest? >>>> >>>> Bill >>>> >>>> >>>> ----------------------------- >>>> >>>> View >>>> MorphViev >>>> ImageView >>>> ContainerView >>>> >>>> ViewGadgetLayoutAbstract >>>> ScrollerGadgetLayout >>>> NullViewGadgetLayout >>>> FixedStretchFixedGadgetLayout >>>> ProportionalGadgetLayout >>>> PreferredExtentsGadgetLayout >>>> GridGadgetRowsLayout >>>> VerticalListLayout >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, August 09, 2010 11:05 PM Subject: Re: [Pharo-project] Early days of an MVP framework > Gary, > > Thanks for the examples. One thing is driving me nuts: in the past, I > thought that creating a new row or column made a morph but did not add it > to the morph being created. Might I have added them redundantly? Does > re-adding a child have no effect or somehow replace it? Is this a > morphi/Polymorph beginner trap? Be honest, I can take it :) > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary > Chambers > Sent: Monday, August 09, 2010 5:45 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Early days of an MVP framework > > And with a stack layout... > > (UITheme builder > newColumn: { > UITheme builder newTabGroup: { > 'First page' -> ((UITheme builder newStack: { > (UITheme builder > newAlphaImage: UITheme current warningIcon > help: nil) > alpha: 0.5. > CircleMorph new > hResizing: #spaceFill; > vResizing: #spaceFill}) > fillStyle: Color red; > hResizing: #spaceFill; > vResizing: #spaceFill). > 'Second page' -> (UITheme builder newPanel > fillStyle: Color green; > hResizing: #spaceFill; > vResizing: #spaceFill)}. > (UITheme builder newRow: { > UITheme builder newOKButton. > UITheme builder newCancelButton}) > listCentering: #bottomRight}) > extent: 200@300; > openInWindow > > Regards, Gary > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, August 09, 2010 11:30 AM > Subject: Re: [Pharo-project] Early days of an MVP framework > > >> This even (to get buttons on right with correct tab key navigation >> ordering... >> >> (UITheme builder >> newColumn: { >> UITheme builder newTabGroup: { >> 'First page' -> (UITheme builder newPanel >> fillStyle: Color red; >> hResizing: #spaceFill; >> vResizing: #spaceFill). >> 'Second page' -> (UITheme builder newPanel >> fillStyle: Color green; >> hResizing: #spaceFill; >> vResizing: #spaceFill)}. >> (UITheme builder newRow: { >> UITheme builder newOKButton. >> UITheme builder newCancelButton}) >> listCentering: #bottomRight}) >> extent: 200@300; >> openInWindow >> >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, August 09, 2010 11:07 AM >> Subject: Re: [Pharo-project] Early days of an MVP framework >> >> >>> Any Morph can use a layoutPolicy. >>> Available are >>> none (position based) >>> Prorportional (frame/fractions/offsets) >>> Table (overly complex too) >>> Row (one of mine, quicker for simple rows) >>> Stack (mine, overlay morphs on top of each other) >>> >>> TEasilyThemed provides some methods like... >>> >>> newRow: {aMorph, anotherMorph} >>> newColumn: >>> >>> Something like this works... >>> >>> (UITheme builder >>> newColumn: { >>> UITheme builder newPanel >>> fillStyle: Color red; >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> UITheme builder newRow: { >>> UITheme builder newOKButton. >>> UITheme builder newCancelButton}}) >>> extent: 200@300; >>> openInHand >>> >>> (can use openInWindow also)... >>> >>> Rather busy today, hope this helps in the meantime... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> >>> To: <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Sunday, August 08, 2010 11:46 PM >>> Subject: [Pharo-project] Early days of an MVP framework >>> >>> >>>> Gary, >>>> >>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt >>>> coaching), until I needed to repeat a "complex" GUI component and >>>> wanted/insisted on doing so with some reuse. Seaside gives us >>>> components on web pages; we need them for GUI code too. I tried >>>> turning >>>> my presenter-like structures into factories that would add morphs to a >>>> single shell, but it fell apart when it came time to set the framing >>>> values. I was not particularly interested in fixing it, because if I >>>> could do that, I would simply build proper composite widgets using the >>>> fix. >>>> >>>> The problem appears to be in SystemWindow, which does some incredibly >>>> complicated things, all of which (correct me if I am wrong) would be >>>> unnecessary if only there were a good set of layout managers. I can >>>> get >>>> very simple-minded about things, but it would make a whole lot more >>>> sense to me to create rows and columns of widgets, adding splitters >>>> between them until the whole things behaves as intended, rather than >>>> writing code (present only in a top-level shell) that tries to split >>>> things up into rows using its own judgment. Not good. I realize you >>>> did not create the situation, and have done wonders to make it work far >>>> better than when you found it. >>>> >>>> Some time ago, I built an emulated widget framework for Dolphin, which >>>> I >>>> needed because the combination of Dolphin's view resources and Windows >>>> itself was too slow for what I was trying to do. That project included >>>> a somewhat strange set of layout classes, but the basics are present, >>>> and it is not Object Arts' IP. I ported the classes to Pharo and did >>>> some work on stub View and Presenter classes that I had added to Pharo >>>> largely to passify my code that I was importing from Dolphin. The >>>> layouts think in terms of emulated widgets, and I see no reason to >>>> change their minds: I might want to replicate the framework. However, >>>> dynamic typing and a couple of extra methods allow them to work with >>>> just about anything. My goals are modest. Being able to compose rows >>>> and columns would do a lot for me. Add splitters and the ability to >>>> fix >>>> the size of some items, and I could almost anything I would need. >>>> >>>> View class>>example >>>> | row column dot square out shell | >>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32. >>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32. >>>> out := Array writeStream. >>>> >>>> row := ContainerView row. >>>> 2 timesRepeat:[ >>>> column := row addSubview:ContainerView column. >>>> 2 timesRepeat:[ >>>> out nextPut:( >>>> column addSubview:ImageView new >>>> ). >>>> ]. >>>> ]. >>>> >>>> out contents with:{ dot copy. square copy. square copy. dot copy. } >>>> do:[ :view :form | >>>> view morph image:form. >>>> ]. >>>> >>>> row rectangle:( 0@0 extent:400@400 ). >>>> row layout. >>>> >>>> shell := StandardWindow labelled:'Hello MVP'. >>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. >>>> >>>> >>>> The above code produces an array of dots and squares, as intended. One >>>> quirk is that the grid does not resize as the shell resizes, a >>>> consequence of my not having hooked it up to resize events. I might >>>> get >>>> some interesting meltdowns once I begin to do that =:0 I used your >>>> PanelMorph as the "view" associated with ContainerView. What, >>>> ContainView isn't a view??? No. The code is biased toward Morphic, >>>> but >>>> hopefully the same code should extend to wx, GTK, etc. Dolphin's views >>>> have a handle instance variable to control the external resource; these >>>> views have an instance variable pointing to their morph. Handling of >>>> sub views works pretty much as in Dolphin: any view/morph can have >>>> children, but adding them is "legal" only for composites. >>>> >>>> Most systems I have seen treat coordinates relative to the >>>> parent/owner, >>>> but not Morphic. I remember seeing plans to make the change, but >>>> nothing after that. The view instances provide a natural place to fix >>>> things, so I took the plunge. If we switch to some other graphical >>>> realization, we can simply remove the the transformation. >>>> >>>> Are the existing splitters as strange as SystemWindow? By that I mean, >>>> would it be reasonable to add them between other morphs and look for >>>> events from them, or will they have to be replaced? I will eventually >>>> need splitters, but I could initially live without them if I can get >>>> reliable composition where I need it. >>>> >>>> There are very few view classes at present. MorphView can wrap almost >>>> anything, so it might be better to create a rich set of presenters >>>> instead. Dolphin's view resources are going to be interesting to >>>> replace. There are some complexities that I suspect are in deference to >>>> Windows, and some that might be avoidable. For our purposes, it might >>>> be enough to use SIXX to serialize a bunch of message sends and gzip >>>> the >>>> results to save memory. Another option might be to rely on class >>>> methods; having full closures won't hurt; they might allow sufficient >>>> hooking that resources in the Dolphin sense won't even be necessary. >>>> The desire for them quickly arises because views get realized in places >>>> know nothing about how the views should be configured; at least I think >>>> that is what happened to me after just a couple of hours. I am far >>>> less >>>> interested in having a graphical view editor than I am in being able to >>>> write **GOOD** code that assembles things as I want. If the result >>>> happens to allow a graphical editor too, so much the better. >>>> >>>> Any interest? >>>> >>>> Bill >>>> >>>> >>>> ----------------------------- >>>> >>>> View >>>> MorphViev >>>> ImageView >>>> ContainerView >>>> >>>> ViewGadgetLayoutAbstract >>>> ScrollerGadgetLayout >>>> NullViewGadgetLayout >>>> FixedStretchFixedGadgetLayout >>>> ProportionalGadgetLayout >>>> PreferredExtentsGadgetLayout >>>> GridGadgetRowsLayout >>>> VerticalListLayout >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] Fwd: Re: Squeaksource XML Parser - Enhanced support for CDATA Sections

by Norbert Hartl

On 10.08.2010, at 10:45, StÃ©phane Ducasse wrote: > Just an api point > > why preservesC... > and not > preserverC > > I'm always confuse with the infinitive and third person singular situation. > You mean preserveC...? The preserve(r)C.. was a typo, right? I think preservesC... qualifies for a testing selector. But as I wrote in my description of the problem I would call it coalesceCDATASections: aBoolean or enableCoalescing disableCoalescing The functionality that is described here is better known as coalescing. And it describes better what is going. If a parser is coalescing two things will happen. CDATA sections will be read in as text nodes and then subsequent text nodes are coalesing into a single text node. my 2 cents, Norbert > Stef > >> Here is an example that demonstrates parsing with CDATA section preservation: >> doc := (XMLDOMParser on: '') >> preservesCDataSections: true; >> parseDocument. >> doc root firstNode >> When evaluated with cmd-p, it produces: >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] Question: How can I add a items to System Browser Window menu?

by StÃ©phane Ducasse

Yes!!! We should move step by step and fix all the points one by one. And since it takes time we should make priority. :) > what would be create is to step by step make all menus easily extenesible. Like nowadays with the world menu and pragmas > > Carla, once I had a similar problem and the only solution was to override that method with a *MyPackage in that method, and add there the menu entried I wanted...this is completly wrong and sucks...but was the only thing I found > > cheers

Aug. 10, 2010

Re: [Pharo-project] 10 year old slides "Stable Squeak"

by StÃ©phane Ducasse

> > >> pharo father :) > > um, no: > "Work as closely as possible with Squeak Central to incorporate refinements into the base system" well you were not there and believe me it is more complex than that :) > And the other goals are different too. Not quite :)

Aug. 10, 2010

Re: [Pharo-project] Why StringHolder

by StÃ©phane Ducasse

Benjamin started and rewrote the recentMessages and friends. If people can review his code it would be great. > Related with the issue http://code.google.com/p/pharo/issues/detail?id=2757 (Issue 2757: Refactor StringHolder) I was looking at the StringHolder hierarchy, and well, it's not very nice. Playing to see how difficult should it be to refactor the hierarchy and decouple a bit those things, I took Workspace off from there, and writing 2 methods it happened to work well (at least with what I tested, hehe). > > Sooo, I wondered why a StringHolder, what responsibilities it has, and what ones should it have... I found that most of the messages a StringHolder understands are for browsing things and inspect things, such as the Paragraph editor does :). And that's why Workspace could do all his stuff when I made him inherit from Object... I think that we should - Replace ParagraphEditor by SmalltalkEditor, TextEditor (did not check but it should be like that in CUIS and Squeak) In Squeak TextMorph >> initialize "TextMorph initialize" "Initialize the default text editor class to use" DefaultEditorClass := SmalltalkEditor. - then we should probably rewrite some parts and do not inherit from StringHolder I never understood why MessageSet is a subclass of Browser :) But I would focus on the > StringHolder class comment says: "I am a kind of Model that includes a piece of text. In some cases, the text can be edited, and in some the text is a method." > > And I smell that its main responsibility is to hold a Text or a String in its contents variable, and all its subclasses are there because of that... And if so, I don't like that inheritance approach :). This is exact. > I want to destroy (literally) that hierarchy :). And maybe it helps us in coming refactors and cleanings, so we can do them with less fear :P. So could you review benjamin code? then check the texteditor/paragraphEditor > > Well, this mail is just for ask for advice and argue about the correctness of this change (or not). > > Thanks for reading up to here! > Guille > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] Fwd: Re: Squeaksource XML Parser - Enhanced support for CDATA Sections

by StÃ©phane Ducasse

Just an api point why preservesC... and not preserverC I'm always confuse with the infinitive and third person singular situation. Stef > Here is an example that demonstrates parsing with CDATA section preservation: > doc := (XMLDOMParser on: '') > preservesCDataSections: true; > parseDocument. > doc root firstNode > When evaluated with cmd-p, it produces: > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] SocketStream enh

by StÃ©phane Ducasse

enjoy them.... Stef On Aug 9, 2010, at 10:56 PM, Lukas Renggli wrote: > I am on holidays, I cannot test this week. Philippe, Julian? > > Lukas > > On 9 August 2010 10:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> May be you missed this call but this is an important one. >> >> On Aug 8, 2010, at 6:43 PM, StÃ©phane Ducasse wrote: >> >>> Hi lukas and others.... >>> >>> I will integrate the following SocketStream tests and before I would love to see if this >>> does not impact seaside >>> >>> http://code.google.com/p/pharo/issues/detail?id=2767 >> >> and related fixes. >> >> >>> >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010