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

Re: [Pharo-project] HTTP client library in Pharo?

by Andrei Stebakov

What's the process of code review for Sqeak/Pharo? I just tried to post my changes for WebClient Monticello repository via "Save" and it got rejected with error "401". Looks like I don't have write access to it. On Sat, Aug 7, 2010 at 1:20 PM, Andrei Stebakov <lispercat(a)gmail.com> wrote: > Yes, that's correct for Set-cookie (the response), each has its own line. > "Cookies: " for request should be all in one line. > > On Sat, Aug 7, 2010 at 8:05 AM, Philippe Marschall <kustos(a)gmx.net> wrote: >> On 04.08.2010 19:15, Andreas Raab wrote: >>> On 8/4/2010 9:57 AM, Mariano Martinez Peck wrote: >>>> Hi Adrei, excellent :) >>>> >>>> BTW, for HTTP Client you should cc Andreas Raab Â or squeak mailing >>>> list.... >>> >>> Squeak-dev please >>> (http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev) >>> >>>> On Wed, Aug 4, 2010 at 6:08 PM, Andrei Stebakov <lispercat(a)gmail.com >>>> <mailto:lispercat@gmail.com>> wrote: >>>> >>>> Â Â I also found that cookies were not correctly sent. >>>> Â Â Every cookie was sent with its own "Cookie: " header which is not >>>> Â Â correct. >>> >>> I'm curious, why do you think that's incorrect? My understanding is that >>> RFC 2616 explicitly allows that: >>> >>> Â Â "Multiple message-header fields with the same field-name MAY be >>> present in a message if and only if the entire field-value for that >>> header field is defined as a comma-separated list [i.e., #(values)]. It >>> MUST be possible to combine the multiple header fields into one >>> 'field-name: field-value' pair, without changing the semantics of the >>> message, by appending each subsequent field-value to the first, each >>> separated by a comma." >> >> You're correct, but that doesn't mean the implementations follow the >> spec :-(. I can only speak for Set-Cookie, there you have to send each >> cookie on a new line because the expires date format includes a comma >> and Firefox and IE can't handle that. >> >> Cheers >> Philippe >> >> >> _______________________________________________ >> 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 Carla F. Griggio

By the way, if that method only has sense when right clicking on a System Window category list, why is it defined in the class Morph? On Tue, Aug 10, 2010 at 1:13 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > Ohh, I understand now. > I was using the OmniBrowser System Browser. > > Either case, I don't know how I can customize the menu that appears when I > right click on a category *without* changing the original code :( I want > to "extend" that, not *change* it, just add a new comand option. > Do you know if it's possible? > > I can change it adding an option in Morph>>buildMetaMenu: evt, but I wanted > to keep that code clean... > > > > On Tue, Aug 10, 2010 at 12:25 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> 2010/8/9 Carla F. Griggio <carla.griggio(a)gmail.com>: >> > Exactly what Guille captured in the image he attached. When I open that >> > window from the World menu it says 'System Browser', although it could >> > actually be an OmniBrowser on the system categories internally... Are >> they >> > two different things? >> >> I don't know which image you are using, some Pharo images includes the >> OmniBrowser package already loaded and this is what you're probably >> opening from the World menu. >> >> It isn't clear from the world menu which browser (System or Omni) >> you're going to open. >> You might want to use both or more system browsers (there are other >> system browsers) at the same time. I use both tools often. >> >> The System Browser is the "classic" browser in Squeak, you may open it >> evaluating >> >> Browser open >> >> The OmniBrowser System Browser is a browser based on the OmniBrowser >> framework and it is opened evaluating >> >> OBSystemBrowser open >> >> I strongly suggest to choose the OmniBrowser way, it is a really good >> framework, nicely supported and there is some documentation in PDF >> format out there. The only drawback I saw is it is hard to develop a >> browser to browse other things which are not "code". >> >> Cheers, >> >> HernÃ¡n >> >> > If they are, how can I open both? (Because until now I thought they were >> the >> > same thing). >> > I might be interested in customizing both :P >> > >> > >> > On Sat, Aug 7, 2010 at 9:13 PM, HernÃ¡n Morales Durand >> > <hernan.morales(a)gmail.com> wrote: >> >> >> >> Hi Carla, >> >> >> >> 2010/8/7 Carla F. Griggio <carla.griggio(a)gmail.com>: >> >> > Hello! >> >> > >> >> > I want to add an item to the menu that appears when you right click >> on a >> >> > category in the System Browser window. >> >> > >> >> >> >> System Browser or OmniBrowser on system categories? >> >> >> >> HernÃ¡n >> >> >> >> _______________________________________________ >> >> 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] Question: How can I add a items to System Browser Window menu?

by Carla F. Griggio

Ohh, I understand now. I was using the OmniBrowser System Browser. Either case, I don't know how I can customize the menu that appears when I right click on a category *without* changing the original code :( I want to "extend" that, not *change* it, just add a new comand option. Do you know if it's possible? I can change it adding an option in Morph>>buildMetaMenu: evt, but I wanted to keep that code clean... On Tue, Aug 10, 2010 at 12:25 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > 2010/8/9 Carla F. Griggio <carla.griggio(a)gmail.com>: > > Exactly what Guille captured in the image he attached. When I open that > > window from the World menu it says 'System Browser', although it could > > actually be an OmniBrowser on the system categories internally... Are > they > > two different things? > > I don't know which image you are using, some Pharo images includes the > OmniBrowser package already loaded and this is what you're probably > opening from the World menu. > > It isn't clear from the world menu which browser (System or Omni) > you're going to open. > You might want to use both or more system browsers (there are other > system browsers) at the same time. I use both tools often. > > The System Browser is the "classic" browser in Squeak, you may open it > evaluating > > Browser open > > The OmniBrowser System Browser is a browser based on the OmniBrowser > framework and it is opened evaluating > > OBSystemBrowser open > > I strongly suggest to choose the OmniBrowser way, it is a really good > framework, nicely supported and there is some documentation in PDF > format out there. The only drawback I saw is it is hard to develop a > browser to browse other things which are not "code". > > Cheers, > > HernÃ¡n > > > If they are, how can I open both? (Because until now I thought they were > the > > same thing). > > I might be interested in customizing both :P > > > > > > On Sat, Aug 7, 2010 at 9:13 PM, HernÃ¡n Morales Durand > > <hernan.morales(a)gmail.com> wrote: > >> > >> Hi Carla, > >> > >> 2010/8/7 Carla F. Griggio <carla.griggio(a)gmail.com>: > >> > Hello! > >> > > >> > I want to add an item to the menu that appears when you right click on > a > >> > category in the System Browser window. > >> > > >> > >> System Browser or OmniBrowser on system categories? > >> > >> HernÃ¡n > >> > >> _______________________________________________ > >> 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] Question: How can I add a items to System Browser Window menu?

by HernÃ¡n Morales Durand

2010/8/9 Carla F. Griggio <carla.griggio(a)gmail.com>: > Exactly what Guille captured in the image he attached. When I open that > window from the World menu it says 'System Browser', although it could > actually be an OmniBrowser on the system categories internally... Are they > two different things? I don't know which image you are using, some Pharo images includes the OmniBrowser package already loaded and this is what you're probably opening from the World menu. It isn't clear from the world menu which browser (System or Omni) you're going to open. You might want to use both or more system browsers (there are other system browsers) at the same time. I use both tools often. The System Browser is the "classic" browser in Squeak, you may open it evaluating Browser open The OmniBrowser System Browser is a browser based on the OmniBrowser framework and it is opened evaluating OBSystemBrowser open I strongly suggest to choose the OmniBrowser way, it is a really good framework, nicely supported and there is some documentation in PDF format out there. The only drawback I saw is it is hard to develop a browser to browse other things which are not "code". Cheers, HernÃ¡n > If they are, how can I open both? (Because until now I thought they were the > same thing). > I might be interested in customizing both :P > > > On Sat, Aug 7, 2010 at 9:13 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> >> Hi Carla, >> >> 2010/8/7 Carla F. Griggio <carla.griggio(a)gmail.com>: >> > Hello! >> > >> > I want to add an item to the menu that appears when you right click on a >> > category in the System Browser window. >> > >> >> System Browser or OmniBrowser on system categories? >> >> HernÃ¡n >> >> _______________________________________________ >> 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 Schwab,Wilhelm K

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: 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: Monday, August 09, 2010 7:05 PM To: Pharo-project(a)lists.gforge.inria.fr 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

[Pharo-project] Why StringHolder

by Guillermo Polito

Hi! Related with the issue http://code.google.com/p/pharo/issues/detail?id=2757(Issue 2757 <http://code.google.com/p/pharo/issues/detail?id=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... 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 :). 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. 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

Aug. 10, 2010

Re: [Pharo-project] TextMorph without being able to be edited?

by Fernando olivero

Did you try in an updated 1.2 image? (Menu tools Software update) Please let me know, because is working fine for me in Gaucho, since a while now. And i'm using an updated 1.2 image. Saludos, Fernando On Aug 9, 2010, at 10:11 PM, Carla F. Griggio wrote: > :D ! Great! Thanks. > > But it seems that a NewTextMorph doesn't understand autoFit: nor padding: > :( > > I don't really care about the padding now, but I'd like to have this morph 'autofitted' :P How come that it works for you (Fernando) and not me? :S > I found that if I send #fitToParagraph to the NewTextMorph instance after I set it's text, it fits OK. > > I still have to try Bill's suggestion. > > Thanks! > Carla > > On Mon, Aug 9, 2010 at 6:27 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes! > > On Aug 9, 2010, at 11:07 AM, Fernando olivero wrote: > > > Try NewTextMorph! > > > > t := NewTextMorph new. > > t > > borderWidth: 1; > > borderColor: Color red; > > color: Color white; > > padding: 5 ; > > readOnly: true; > > autoFit: true ; > > text: 'I present my text as read only ' asText ; > > openInWorld. > > > > Fernando > > On Aug 7, 2010, at 12:26 PM, Carla F. Griggio wrote: > > > >> Hi again, everyone! > >> > >> I think this might be really really silly, but I couldn't find a way to show a TextMorph without the ability to edit it's text. > >> If I use a StringMorph to show a paragraph, it looks horrible, but if I use a TextMorph and click on it, a blue border appears and I'm able to edit the text, I don't want that to happen. > >> > >> Is there another morph for showing text that only shows text and nothing else? Or a property of TextMorph that I'm missing? > >> > >> > >> Thanks! > >> Carla > >> <ATT00001..txt> > > > > _______________________________________________ > > 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 > > <ATT00001..txt>

Aug. 9, 2010

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

by Schwab,Wilhelm K

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

Aug. 9, 2010

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

by Schwab,Wilhelm K

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

Aug. 9, 2010

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

by jaayer

============ Forwarded message ============ >From : jaayer To : "Jan van de Sandt" Date : Mon, 09 Aug 2010 14:55:29 -0700 Subject : Re: Squeaksource XML Parser - Enhanced support for CDATA Sections ============ Forwarded message ============ ---- On Mon, 09 Aug 2010 04:44:07 -0700 Jan van de Sandt wrote ---- >Hello, > >Ok, I understand the problem :-) thanks for explaining it. > > >Here is a new version. In this version the XMLDOMParser has an extra property preserveCDATASections so the behaviour is now configurable. For now the default value of this property is true. Thank you for the patch. I have merged it in, but with the following modifications: 1) Preservation of CDATA sections is disabled by default, as most of the time you don't really care whether parsed character data originally contained &, < or other pseudoentities to escape special characters or if those special characters were guarded within a CDATA section. 2) #addCDATASection: has not been added. I really don't want a proliferation of #add* methods in XMLElement or XMLNodeWithElements for every node type. #addContent: is special, as it accepts a node or a string, and #addElement; was once needed for the special handling element nodes required but is no longer needed. #addNode: should be preferred. 3) The messages added to XMLDOMParser were renamed to #isInCDataSection, #preservesCDataSections, and #preservesCDataSections: to make it clearer that they take or return boolean values. 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:

Aug. 9, 2010