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
