September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo breakpoints

by stepharo

On 13/9/14 10:54, Johan Brichau wrote: > Hi guys, > > As described in this issue on the Seaside tracker [1], it appears that setting a breakpoint on a method simply sends the #break message. > As #break is not an uncommon method name, the choice for this makes is a de-facto reserved method in Pharo. > > Would it not be better to rename #break to #_break ? This will avoid unintended clashes. I would avoid using _break because we have halt and not _halt. Now for break we could have Halt break or something like that to remove from Object selector space. > > Johan > > [1] https://code.google.com/p/seaside/issues/detail?id=829 >

Sept. 13, 2014

AlphaImageMorph performance

by kilon alios

so I sat down to find a good way to import pngs with transparence in pharo and animate them and I ended up to this code morph:= AlphaImageMorph new. morph openInWorld . form1 :=Form fromFileNamed:'/Users/kilon/Pictures/box.png'. form2 :=Form fromFileNamed:'/Users/kilon/Pictures/box2.png'. [(1 to: 100) do: [ :index| morph image: form1 . (Delay forMilliseconds: 2) wait. morph image: form2 . (Delay forMilliseconds: 2) wait. ]]fork. gave me a basic animation then I did the proper thing and I created my own class subclassing AlphaImageMorphing and used stepping every 40 milliseconds (25 fps) to create an animation of 2 frames , frame 1 is image box.png and frame 2 is image box2.png. Both images are 600x600 and contain transparency. Now one morph is fine , seems to work ok and does not raise my cpu much. However when I kept adding instances of the class I found out that after 3 the animation was considerably slow down, pharo also slow down with slow response to my command , when I reached 6 instance I saw failed redrawing of the moprh which was like it was cutting pieces out of the image for a second or so and pharo interaction was quite slow. The cpu one of the four cores were up to 50%. CPU consumption is not bad at all , I compared with playing a youtube FULL HD video which was the same resolution and it was consuming 30% of the cpu. However I wonder if this the best way to do this. Its clear that there is no way with my current solution I can fully animate a big pharo window that is more than 1200x1200 without serious flickering and ideally I should not animate more than 1000x1000 for smooth animation. So is this all ? Are there any improvements I may apply ? Would Athens be faster in this case ? I did not try because Athens is using Morphic anyway so it should be same if not worse.

Sept. 13, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by kilon alios

" I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? " yes exactly. Blender can render in all popular graphics files, most used are png. Animation frames can be rendered each frame in its own file. So basically its a lot like the average games out there. "I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing." ok "For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result." I fail to understand how your bitmap source is SVG for me bitmap is a raster graphic format svg is procedural graphic format. Two opposite things. "Sure. The downpoint, you will depend on one additional layer." dependency is not an issue. Afterall the graphic files themselves will be far bigger download even more so if the GUI becomes very large. "Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious." Well Blender besides creating 3d objects (which can be used as 2d objects too) it can also create 3d unrendable objects. That means that objects produce no graphics and have the role of placeholders or helpers, for example when you want an emitter of light or emitter of a physical power like gravity or wind. Those are called dummy objects and I could use them to give characteristics to the graphics , for example I could use a dummy to define the are of influence of a mouse click , or what type of event the bitmap will respond to. That means you wont have to import the graphics manually to pharo and create a separate morph for each bitmap and then set the events but rather press a button in blender and then Ephestos will import then bitmaps to pharo , set the events and create the morphs automagically. So basically you will be using Blender as a GUI designer. "Use fuel to store the state of your application objects." ah nice so fuel is a good candidate. I will also take a look at Dr Geo and Phratch , both apps have custom GUIs and use only Morphic (Dr Geo using Athens for the geometry primitives) .

Sept. 13, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Hilaire

Hi, Le 13/09/2014 11:05, kilon alios a Ã©crit : > have integration with Blender so my idea now is to drop Hyperion and > instead make the GUI inside Blender and export it as a set of animatable > bitmaps. I am curious. You mean rendering Bitmap from blender, for later use in Pharo UI? > > My dilemma is what graphic library to use : a) Morphic b) Athens or > c)Roassal I will suggest bare bone Morphic mainly, then Athens when you need vectorial drawing. > What I need is the following: > > 1) Ability to render small bitmaps fast and do animation , big bitmaps > will be mostly static used for backgrounds You can do that from Athens over Morphc canvas. > 2) Basic interaction ability , mouse left and right click , mouse drag , > mouse click press and release events. Of course keyboard events too no problem > 3) The ability to scale up and down images with minimum distortion For iStoa I decided to go purely Morphic, I have a lot of bitmap. Bitmap source is SVG, then converted to PNG, overscaled for production use. Then from iStoa, depending on the application window extent, the bitmap are downscaled accordingly, I am pretty satisfied by the result. > 4) The ability to render text smoothly and scale it up and down That's may be more tricky. I have issue to deal with when migrating DrGeo to Athens regarding text. I forgot about the details, but the hacks are in the Morph object for text rendering in DrGeo. Igor was very kind to help accurately on those problems. > 5) Transparency also plays a big role in layering those images Never dig on that, I may need that for DrGeo when importing bitmap. > > I think so far that Roassal is the best candidate because it also > integrates well with Morphic and Athens. Also I may still need some > vector graphics for example charts or dynamic graphics that will depend > on user input that would not be suitable to do strictly with SVG so the > morphic option is getting weaker and weaker. Sure. The downpoint, you will depend on one additional layer. > > I wanted a second opinion though since you are much more experienced > than me. > > I may also create an API for creating such GUIs with Blender for Pharo. Nice. What will be the expected outcomes of such API, I am not sure to understand and I am curious. > Another thing I am wondering is how to download all these images to > Pharo , what you guys use to do download big data to Pharo , maybe Fuel ? Images=pictures? Use plain PNG files! Use fuel to store the state of your application objects. Good work! Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

Sept. 13, 2014

Re: [Pharo-dev] Thanks :)

by Craig Latta

Hooray! :) -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Sept. 13, 2014

Re: [Pharo-dev] fosdem 2015

by Craig Latta

Hoi Stephan-- > I will put out a proposal for a devroom, yes. That is no guarantee > that we will get one, the amount of space is limited. Looking forward to it! -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Sept. 13, 2014

Re: [Pharo-dev] Thanks :)

by Alexandre Bergel

Indeed! > Le 12-09-2014 Ã 16:51, stepharo <stepharo(a)free.fr> a Ã©crit : > > Every time we improve the system with a little change, the system gets better. And in Pharo we do it daily. Thank you all for all your changes and enhancements. **You** make Pharo cool. > > http://pharoweekly.wordpress.com/2014/09/12/there-is-no-such-thing-as-an-un… >

Sept. 13, 2014

The Dilemma: Building a Futuristic GUI for Ephestos

by kilon alios

So far Ephestos has gone quite well and I am satisfied with my progress so far. I think its time to start thinking about a GUI for it. I was always very interested in creating futuristic GUIs like this http://vimeo.com/68113915 At first I thought about a project "Hyperion" to explore the idea of creating a vector editor in pharo, it was a fun experiment to see also the potential of Athens. However the more I think about the more unnecessary seems to me the use of SVG graphics. Back then I did not have integration with Blender so my idea now is to drop Hyperion and instead make the GUI inside Blender and export it as a set of animatable bitmaps. My dilemma is what graphic library to use : a) Morphic b) Athens or c)Roassal What I need is the following: 1) Ability to render small bitmaps fast and do animation , big bitmaps will be mostly static used for backgrounds 2) Basic interaction ability , mouse left and right click , mouse drag , mouse click press and release events. Of course keyboard events too 3) The ability to scale up and down images with minimum distortion 4) The ability to render text smoothly and scale it up and down 5) Transparency also plays a big role in layering those images I think so far that Roassal is the best candidate because it also integrates well with Morphic and Athens. Also I may still need some vector graphics for example charts or dynamic graphics that will depend on user input that would not be suitable to do strictly with SVG so the morphic option is getting weaker and weaker. I wanted a second opinion though since you are much more experienced than me. I may also create an API for creating such GUIs with Blender for Pharo. Another thing I am wondering is how to download all these images to Pharo , what you guys use to do download big data to Pharo , maybe Fuel ?

Sept. 13, 2014

Pharo breakpoints

by Johan Brichau

Hi guys, As described in this issue on the Seaside tracker [1], it appears that setting a breakpoint on a method simply sends the #break message. As #break is not an uncommon method name, the choice for this makes is a de-facto reserved method in Pharo. Would it not be better to rename #break to #_break ? This will avoid unintended clashes. Johan [1] https://code.google.com/p/seaside/issues/detail?id=829

Sept. 13, 2014

Re: [Pharo-dev] Starting with Roassal 2

by Juraj Kubelka

Yes, you can use SVG path as a shape for an element. What you chose really depends on your objective. If you want to draw nodes (elements) and connect them with edges (lines), I guess, the preferred API is Roassal2. On Sep 12, 2014, at 7:02 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > ah thank you very much, thats exactly what I was looking for. I will study Trachel too. I also found that I can do something similar using a SVG path with Roassal. > > On Sat, Sep 13, 2014 at 12:58 AM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > I think the intention of Roassal lines is to be connected with elements. If you want only draw lines without any connection to elements, use directly Trachel. I guess > > -=-=-=- > | v line | > v := RTView new. > line := TRLineShape new from: 0@0 to: 100@100 color: Color blue. > v canvas addShape: line. > ^ v open > -=-=-=- > > Cheers, > Juraj > > On Sep 12, 2014, at 6:53 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > >> well thats not an one liner and you still connect elements with it. I just wanted to pass coordinates to a line and draw it. So I would prefer it if I could pass points instead of elements. >> >> On Sat, Sep 13, 2014 at 12:38 AM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >> OK, then you can write: >> >> -=-=-=- >> | v elements edge | >> v := RTView new. >> elements := (RTEllipse new >> size: #yourself; >> color: Color red) + RTLabel elementsOn: #(10 20). >> edge := RTDirectedLine new >> color: Color blue; >> edgeFrom: elements first to: elements second. >> v >> addAll: elements; >> add: edge. >> RTGridLayout on: elements. >> elements @ RTDraggable. >> ^ v open >> -=-=- >> >> Cheers, >> Juraj >> >> On Sep 12, 2014, at 6:30 PM, kilon alios <kilon.alios(a)gmail.com> wrote: >> >>> yes i know about the example of a line connecting with other shapes. I wanted just a simple line by itself starting from one point and ending to another in a single line of code. >>> >>> On Sat, Sep 13, 2014 at 12:26 AM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >>> I have checked RTDirectedLine and it is not supposed to use the way you want. Basically RTEdge is the object you want to manipulate with. >>> >>> I do not know what is the objective of your example. But there is way how you could write it. >>> >>> -=-=- >>> | v elements models | >>> models := (10 to: 60 by: 1). >>> v := RTView new. >>> elements := (RTEllipse new size: #yourself; color: Color red) + RTLabel elementsOn: models. >>> v addAll: elements. >>> RTEdge buildEdgesFromObjects: models from: #yourself to: [ :i | i // 2 ] inView: v. >>> RTGridLayout on: elements. >>> elements @ RTDraggable. >>> v @ RTDraggableView. >>> v canvas color: Color black. >>> v open. >>> -=-=- >>> >>> Cheers, >>> Juraj >>> >>> On Sep 12, 2014, at 5:03 PM, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>> > Ok here comes the first question >>> > >>> > how I change the background color of RTView ? >>> > >>> > also >>> > >>> > when I do this >>> > >>> > v := RTView new. >>> > shape := RTEllipse new size: 20; color: Color red. shape := shape + RTLabel. >>> > es := shape elementOn:'hello'. v add: es. >>> > line := RTDirectedLine new pointsFrom: 20@20 To: 30@30. >>> > es2 := line element.v add: es2. >>> > es @ RTDraggable. >>> > v @ RTDraggableView . >>> > v open. >>> > >>> > I am getting an error >>> > >>> > MNU Array >> element >>> > >>> > why ? >>> > >>> >>> >>> >> >> > >

Sept. 12, 2014