Gary, I have a composite GUI that appears to work. I need to mask about 3,000 images in pairs of three that repeat in sequences (don't worry, you'll be happier if you don't understand<g>). I am hoping to use the first triad in each sequence as the basis for a "fill down" command that will hopefully leave me making only minor edits to most of the masks.
Thanks! Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Schwab,Wilhelm K [[email protected]] Sent: Monday, August 09, 2010 7:05 PM To: [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Schwab,Wilhelm K Sent: Monday, August 09, 2010 5:06 PM To: [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Gary Chambers Sent: Monday, August 09, 2010 5:45 AM To: [email protected] 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: 2...@300; openInWindow Regards, Gary ----- Original Message ----- From: "Gary Chambers" <[email protected]> To: <[email protected]> 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: 2...@300; > openInWindow > > > Regards, Gary > > ----- Original Message ----- > From: "Gary Chambers" <[email protected]> > To: <[email protected]> > 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: 2...@300; >> openInHand >> >> (can use openInWindow also)... >> >> Rather busy today, hope this helps in the meantime... >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Schwab,Wilhelm K" <[email protected]> >> To: <[email protected]> >> 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:4...@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 >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
