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

[Pharo-project] Issue 670: Should clean Morph menu
by Guillermo Polito June 4, 2010

June 4, 2010

Hi! I began looking at this issue, and made a list of the menu items that exists in the default morph menu. Maybe we can choose which ones should be removed and which ones are really used. Here it goes: grab copy to paste buffer collapse delete copy text go behind add halo duplicate embed into-> PasteUpMorph SystemWindow resize change color... drop shadow-> show shadow shadow color... shadow offset... layout-> no layout proportional layout table layout change layout inset... child layout-> disable layout in tables horizontal resizing-> rigid shrink wrap space fill vertical resizing-> rigid shrink wrap space fill table layout-> reverse table cells clip to cell size rubber band cells change cell inset... change min cell size... change max cell size... list direction-> ... wrap direction-> ... cell positioning-> ... list centering-> ... wrap centering-> ... list spacing-> ... cell spacing-> ... provide clipping submorphs inspect explore browse hierarchy save morph in file attach to resource show actions debug-> inspect morph inspect owner chain inspect model explore morph browse morph class browse model class explore view hierarchy call #tempCommand define #tempCommand open editing edit label... Cheers, Guille

4 7

[Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]
by Igor Stasenko June 3, 2010

June 3, 2010

On 24 May 2010 13:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On May 23, 2010, at 11:04 PM, Igor Stasenko wrote: > >> 2010/5/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: >>> Hi, may I ask how you are rendering these fonts? You parse the glyphs and >>> then render lines with opengl or use freetype to render to a texture without >>> antialiasing or both? >> >> Squeak has already a TT font reader, so i just taking the data from there >> and piping to GPU. >> What you see here is freely scalable vector/curve rendering done >> completely on GPU. >> >>> If you asked me, I'd say I like the method but for >>> fonts they look a bit blury, I'd say too much for the smaller ones. >> >> I think this is best what you can achieve without hinting / subpixel AA. >> >>> Also, what are you working on? >>> >> I once did a GLCanvas, >> and now i want to reiterate and improve it using new callout mechanism >> (NativeBoost), >> and full coverage of OpenGL API, with all extensions available at your disposal. > > Igor it would be good it we could have > > NativeBoostRomeCanvas > > if you see what I mean :) > Yes, i actually want to do that. I plan to inject the new methods into a Morph Morph>>fullDrawOnRomeCanvas: aCanvas Morph>>drawOnRomeCanvas: aCanvas which should tell the morph to use a different instructions/commands to perform drawing, to conform with RomeReferenceCanvas protocol. I don't want to repeat a balloon canvas protocol. Then, eventually, when we will have everything ready, we will be free to use different rendering backend than Balloon canvas. And its important to make it a non-intrusive. So, the plan is: - create a separate package, which will contain extension methods to Morph and its various subclasses. And maybe some little classes. - this package !!_should not_!! have any dependencies on Rome , and should be loaded cleanly, even if you don't have Rome installed. It only should conform with Rome canvas protocol for implementing rendering. This will ensure a backend agnostic nature of new morphic rendering code. If you think this plan is cool, then lets pick a package name and repository, and i will start happy coding :) >> >>> Regards, >>> Â Â Â Â Â Â Javier. >>> >>> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

3 12

[Pharo-project] Using WebClient
by GermÃ¡n Arduino June 2, 2010

June 2, 2010

Hi: I'm trying to automate some operations on a web page that requires authentication. I managed to arrive to the form that I need to process, authenticated without problems. But I can't figure out how to process the button (is a button of this type: <input class="lButton" style="" name="submit_search" value="Create File" type="submit"> ) to execute the Create File action. The form have two dates (that I can calculate and fill in) but I can't to imagine how to process the submit button programmatically. Any hint will be appreciated. Cheers. -- ================================================= GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================

4 7

[Pharo-project] [update 1.1] #11382
by StÃ©phane Ducasse May 31, 2010

May 31, 2010

11382 ----- - Issue 2462: Preference Browser should be removed from the world menu. Thanks Guille. - Issue 2094: Compiler CUIS 22 fixes. Thanks henrik/juan - Issue 2466: MethodReference>> asStringOrText. Thanks Adrian Stef

1 0

[Pharo-project] Manuia Memory Monitor
by Torsten Bergmann May 31, 2010

May 31, 2010

BTW: There is also the old "MemoryUsage" from Squeak (see [1]/[2]). Dont know if it still works [1] http://map.squeak.org/package/5307d593-6aa4-496a-94fa-68a5ed82a3ba [2] http://web.nilpotent.org/software/smalltalk/MemoryUsage3.st.gz -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

3 4

[Pharo-project] Manuia Memory Monitor
by Alexandre Bergel May 31, 2010

May 31, 2010

Hi! Between two latexing session, I did a 3 hours long coding session. I produced Manuia, a real-time memory monitor. I attached a screenshot to this email. You can try it by: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSpy'; load. (Smalltalk at: #ConfigurationOfSpy) perform: #loadDefault If you use a Pharo 1.1 then world menu/tools/Manuia Memory Monitor . Else, evaluate "ManuiaMonitor new open" Green curve is about the memory consumption: when it goes up, when you consuming memory. Vertical bars indicate that at least 10 incremental garbage collect was realized. There is a probe class button. Click on it, enter the name of a class, then you can see the evolution of the number of instances. It is just a small experiment I did. I haven't got the time to intensively use it. Feedbacks are very welcome. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 7

[Pharo-project] Rome/Athens notes
by Igor Stasenko May 31, 2010

May 31, 2010

Hi, i found rome API very close to OpenVG. Still OpenVG is a bit superior :) So, i'm using it as a guide to model/implement Rome interfaces. So, here is my thoughts (i also having a draft class skeleton for them): Paints: Paint is an object, which when applied to path, renders(draws) the path using paint's unique properties. I defined two methods in paint's base class: fillPath: aPath on: aCanvas self subclassResponsibility strokePath: aPath on: aCanvas self subclassResponsibility So, to draw a path, one should use a concrete paint to either fill it or stroke it (or both, if you want, but its handled by canvas and still will end up with separate fill & stroke requests to paint). I started from a quite basic things: NullPaint Paint which does not performs any drawing. Applying this paint to any path won't lead to any changes/processing. A simple OO approach to define 'nothing' :) SolidColorPaint instanceVariableNames: 'color' Paint with solid color. Most trivial thing which can be done :) RomePen instanceVariableNames: 'paint capStyle joinStyle width dash' A 'pen' paint is just encapsulating a set of properties, which is used for stroke. It is using another paint, which should handle the fills (in 'paint' ivar), while various stroke properties should be handled by itself. Filling with pen, will be the same as filling with its paint. While doing a stoke is different (includes path processing, given the values of pen's properties etc etc). I'm not sure with this part. Maybe stroke properties would be better to leave in canvas? Both OpenVG and Rome seems like following this road, but i don't quite like that stroke properties is global for canvas and lacking a proper encapsulation. CompositePaint Quite dumb thing. Holds a list of paints. When asked to fill or stroke the path, applies paints from own list. GradientPaint (abstract) LinearGradient RadialGradient etc.. paints which will use gradients for fills. Nothing fancy :) Canvas protocol: selectFill: anObject fill := anObject asRomePaintOn: self - selects a paint which will be used for fills. selectPen: anObject pen := anObject asRomePaintOn: self - selects a paint which will be used for stokes. stroke: anObject | path | path := anObject asRomePathOn: self. fill strokePath: path on: self. - stroke a path using currently selected 'pen' paint fill: anObject | path | path := anObject asRomePathOn: self. fill fillPath: path on: self. - fill path using paint for fills fillAndStroke: anObject | path | path := anObject asRomePathOn: self. fill fillPath: path on: self. pen strokePath: path on: self - fill and stroke path. And from that point, i wonder, do we need to have a paint's selection mechanisms at all? Because, we could simply do: canvas fill: myPath with: myPaint instead of: canvas selectFill: myPaint. canvas fill: myPath. Because you anyways can't draw a paths without paints, i don't see why canvas should have a notion of 'current fill' or 'current paint'. I think that with paint's encapsulation, its not necessary. I'd like to hear your thoughts about it. -- Best regards, Igor Stasenko AKA sig.

3 8

May 31, 2010

cool I really want to see how we can get a nice momentum on that front :) Stef On May 31, 2010, at 4:45 PM, Juan Vuletich wrote: > Hi Stef, Igor, > > (copied Igor too) > > StÃ©phane Ducasse wrote: >> On May 30, 2010, at 10:57 PM, Igor Stasenko wrote: >> >> >>> On 30 May 2010 23:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> cool post >>>> >>>> >>> Yeah, these things are quite interesting. Except that not much people >>> actually interested in it :) >>> >> >> I do not think so. >> Good posts are read more that you believe. Now in mailing-list the numbers of mails >> cut the knowledge after a point. >> >> >>> Here's another thing, which can be done right (if we want). >>> >>> Rome/OpenVG Paths is actually nothing else than a special kind of more >>> general thing - shape. >>> >>> So, at very basis, we should have only two components for painting: >>> shape and paint. >>> And in fact we need to support only a single operation: fill the shape >>> with given paint. >>> (The path stroke could be seen as a special kind of fill) >>> >>> >>> So the question is: Really. Why we should constrain ourselves with >>> specific things >>> from a very starting, by cutting out a most basic (and abstact ideas) behind? >>> >>> There are infinite number of ways, how one could define a shape. >>> While paths is only a small, yet effective representation of shapes. >>> In same way there are infinite number of ways how one could define a paint. >>> >>> Then this looks like a strong basis for building-up a powerful & >>> flexible graphics engine :) >>> >> >> I do not know. Do the other frameworks outside smalltalk use something else >> than paths? >> I think that we should start - making rome working. We are nearly there >> - test it >> - refactor it. >> - I would like to see the canvas for morphic30 too. >> - refactor the system to use that. >> stef >> > > The current Morphic 3 canvas is based on SVG / OpenVG. The main element is the path. But the fundamental building block is a trajectory of a pen that defines shapes, and fills. So it is easy to extend to ways to define shapes other than paths. > > BTW, the Morphic 3 canvas is separated from the Morphs and their geometry. This means that Morphic 3 morphs could be used with Athens / Rome / Cairo, or even with Balloon. It also means that the Morphic 3 canvas could be used with Morphic 2, Tweak or any other framework that can call an OpenVG like api. > > I'm working on an update to the Morphic 3 web page right now. Will be ready today or tomorrow, and it will include some actual samples of rendering. > > Cheers, > Juan Vuletich

1 0

Re: [Pharo-project] Rome/Athens notes
by Igor Stasenko May 31, 2010

May 31, 2010

On 31 May 2010 17:45, Juan Vuletich <juan(a)jvuletich.org> wrote: > Hi Stef, Igor, > > (copied Igor too) > > StÃ©phane Ducasse wrote: >> >> On May 30, 2010, at 10:57 PM, Igor Stasenko wrote: >> >> >>> >>> On 30 May 2010 23:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>> cool post >>>> >>>> >>> >>> Yeah, these things are quite interesting. Except that not much people >>> actually interested in it :) >>> >> >> I do not think so. >> Good posts are read more that you believe. Now in mailing-list the numbers >> of mails >> cut the knowledge after a point. >> >> >>> >>> Here's another thing, which can be done right (if we want). >>> >>> Rome/OpenVG Paths is actually nothing else than a special kind of more >>> general thing - shape. >>> >>> So, at very basis, we should have only two components for painting: >>> shape and paint. >>> And in fact we need to support only a single operation: fill the shape >>> with given paint. >>> (The path stroke could be seen as a special kind of fill) >>> >>> >>> So the question is: Really. Why we should constrain ourselves with >>> specific things >>> from a very starting, by cutting out a most basic (and abstact ideas) >>> behind? >>> >>> There are infinite number of ways, how one could define a shape. >>> While paths is only a small, yet effective representation of shapes. >>> In same way there are infinite number of ways how one could define a >>> paint. >>> >>> Then this looks like a strong basis for building-up a powerful & >>> flexible graphics engine :) >>> >> >> I do not know. Do the other frameworks outside smalltalk use something >> else >> than paths? >> I think that we should start Â Â - making rome working. We are nearly there >> Â Â Â Â - test it >> Â Â Â Â - refactor it. >> Â Â Â Â - I would like to see the canvas for morphic30 too. >> Â Â Â Â - refactor the system to use that. >> stef >> > > The current Morphic 3 canvas is based on SVG / OpenVG. The main element is > the path. But the fundamental building block is a trajectory of a pen that > defines shapes, and fills. So it is easy to extend to ways to define shapes > other than paths. > How about shapes which defined by other means than trajectory of pen? Suppose things like parametric shapes. Circle/ellipse for instance could be defined by 1 coordinate and radius(es). > BTW, the Morphic 3 canvas is separated from the Morphs and their geometry. > This means that Morphic 3 morphs could be used with Athens / Rome / Cairo, > or even with Balloon. It also means that the Morphic 3 canvas could be used > with Morphic 2, Tweak or any other framework that can call an OpenVG like > api. > > I'm working on an update to the Morphic 3 web page right now. Will be ready > today or tomorrow, and it will include some actual samples of rendering. > Oh. This is indeed good news. I read about Morphic3 before, but you never mentined the details about it infrastructure. Now, its really nice to know that it is based on similar concepts. > Cheers, > Juan Vuletich > -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] Fwd: [squeak-dev] traits
by Mariano Martinez Peck May 31, 2010

May 31, 2010

Hi Norbert: I am not sure the current situation in Squeak but in Pharo I know it is used in some places. I think in some Collection testing and Nile framework...but I am not sure. Anyone can help? Cheers Mariano ---------- Forwarded message ---------- From: Norbert Fortelny <norbert.fortelny(a)gmail.com> Date: Wed, May 19, 2010 at 5:17 PM Subject: [squeak-dev] traits To: squeak-dev <squeak-dev(a)lists.squeakfoundation.org> Could anyone point me to sample code using traits in squeak. Poked around a bit but couldn't find anything. thanks and sorry if that is inappropriate here. Norbert

2 1