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

Re: [Pharo-dev] Morph to TakskbarMorph

by Nicolai Hess

2014-12-28 15:59 GMT+01:00 Roberto Minelli <roberto.minelli(a)usi.ch>: > By "PluggableButtonMorph contained in the TakskbarMorphâ I mean the > PluggableButtonMorph that sits in the TakskbarMorph and ârepresentsâ a > given SystemWindow in the IDE space. > Usuallay this works with dependents or announcement registrations. That means, if the SystemModel is the "model" of the PluggableButtonMorph, the PluggableButtonMorph is the SystemWindows dependents array, and/or the button registers himself for the SystemWindows announcer. But actually I am a bit suprised, because it seems the TaskbarMorph rebuilds its whole TaskbarButton array *everytime* something changes. For example, I have 4 workspaces open PluggableButtonMorph allInstances size. -> 8 Click multiple times on the 4 workspace taskbar buttons or put the different Workspace windows to front: PluggableButtonMorph allInstances size. -> 40 Smalltalk garbageCollect. PluggableButtonMorph allInstances size. -> 8 > > Hope it is clear. > > Thanks for any help! > > Cheers, > R > > > > On 28 Dec 2014, at 15:50, Roberto Minelli <roberto.minelli(a)usi.ch> > wrote: > > > > Hi, > > > > I am trying to understand some Morphic. It looks like the dark side. > > > > Anyway, I am trying to reconstruct the relationship between a Morph, say > a SystemWindow and its PluggableButtonMorph contained in the TakskbarMorph. > Any suggestion? > > > > Each PluggableButtonMorph in the TakskbarMorph has as #model the ârealâ > window, but I cannot find the inverse relationship. > > > > Cheers, > > R > > >

Dec. 31, 2014

Re: [Pharo-dev] Jun4Pharo so exciting :)

by kilon alios

I dont doubt for a minute it will be a difficult task , this is why I chose not to do it and instead I went down the easy route of relying on existing graphics engines in my case Blender which I try to expose it to Pharo. I learned the hard way how much time one can waste doing things the hard way. On Tue, Dec 30, 2014 at 10:59 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Is this a real concern ? Afterall vector data is a lot less complex than >> 3d geometry and CPUs nowdays are multicore. > > For really smooth and complex animations, yes it is a concern. > Performance. If the objective is to draw a static shape or a slow > animation, it is not a big problem. Also CPU <-> GPU data transferring is > an expensive operation that has to be avoided if possible. > > Actually 2D vector data is more complex. 3D geometry comes already > processed to be directly rendered, and it is represented by only two > arrays: vertices and indices. > > In contrast, 2D vector data is represented by a stream of commands that > have to be evaluated. > > BTW, we don't have support for real multithreading in Pharo, and we will > not have it for a very long time. The closest thing to real multithreading > that we are getting in the near term > >> Don't know about the Opengl backend of Cairo. Igor also once shown me a >> Spec for vector graphics on OpenGL by Khronos Group. >> > Well, there is OpenVG designed for mobile platform(Android and iOS). > OpenVG is not supported by desktop graphic cards vendors. > > The closest thing we have in the desktop world is the NV_path_rendering > NVIDIA only extension. At least the paper that describes this extension is > really good. The bad thing is that it depends at least partially in the > Loop-Blinn algorithm that is patented, if I remember right. > > Newest OpenGL versions also come with dynamic tesselation geometry shaders >> that basically increase the detail of a 3d object the closer a camera gets >> to it which is similar to vector graphics which is something that could >> also work as basic via NBOpenGL to bring Athens to 3d side completely >> bypassing Cairo. >> > > In first place, not all of the world have at least DX11/OpenGL 4.xx level > graphic card. But, it does not matter too much because the hardware > tessellation does not help you anything with the main problem. > > The biggest problem is that 2D vector paths can be concave, and they can > have a hole . The easiest way to support it is by using the stencil buffer, > and in my opinion is the method with the better results. In fact, the > NV_path_rendering extension is implemented in this way, but directly in the > OpenGL driver. > > This method renders first the tessellated path with a triangle fan, with > the stencil test set to invert the stencil buffer bits. In this way, the > stencil buffer holds 1 in the points that are inside of the path, and 0 in > the points that are outside of the path. > > Then, the bounding box of the path is covered with fill color/gradient, > but with the stencil test set to only pass when the stencil buffer value is > 1, and to also clear the stencil buffer in the covered region during the > process to allow rendering more paths elements. > > Each one of the changes to the way the stencil buffer is used involves a > state change, which is expensive. I think this is the reason of why NVIDIA > implemented their extension directly in the OpenGL. > > I know of these problems because I implemented once the stencil method in > C++ with OpenGL. > > The old opengl Cairo backend worked by triangulating the paths. > Triangulation of concave geometry is hard to do, and there some degenerate > case in which it produces bad results. > > Best regards > Ronie > > 2014-12-30 16:58 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > > Is this a real concern ? Afterall vector data is a lot less complex than >> 3d geometry and CPUs nowdays are multicore. >> >> Don't know about the Opengl backend of Cairo. Igor also once shown me a >> Spec for vector graphics on OpenGL by Khronos Group. >> >> So there are alternatives but as always it will require someone doing the >> hard work to bring that functionality to Pharo. >> >> Newest OpenGL versions also come with dynamic tesselation geometry >> shaders that basically increase the detail of a 3d object the closer a >> camera gets to it which is similar to vector graphics which is something >> that could also work as basic via NBOpenGL to bring Athens to 3d side >> completely bypassing Cairo. >> >> On Tue, Dec 30, 2014 at 9:18 PM, Ronie Salgado <roniesalg(a)gmail.com> >> wrote: >> >>> Athens uses Cairo , Cairo can be used with OpenGL. You can use Cairo to >>>> apply a 2d vector graphic as a texture to a 3d polygon. Cairo website shows >>>> several examples of this. That means its possible to have 2d vector >>>> graphics in 3d space as if its true 3d. >>>> >>> I do not think that is going to work easily with the best performance >>> possible. Cairo could be using OpenGL, but probably in a different OpenGL >>> than the one that is being used for 3d graphics. >>> >>> In addition, the Cairo OpenGL backend is experimental ( >>> http://cairographics.org/OpenGL/) . Currently you have to render into a >>> surface in CPU, then transfer it into GPU and then render the polygon. A >>> naive version using the OpenGL backend is going to have GPU->CPU->GPU >>> roundtrip >>> >>> If we are using this route, I think that is better to just use the >>> current version of Athens for this. With Athens we can render into a Form, >>> which can be used to populate a Woden/Roassal texture or transferred >>> directly to OpenGL. This has the advantage of not having a explicit >>> dependency in Cairo. I guess that I will make a demo of this later. It >>> should be easy. >>> >>> I think that a longer term approach could be having a custom renderer, >>> tailored for Athens using OpenGL or maybe OpenCL. >>> >>> 2D vector graphics are really hard. In my opinion they are harder than >>> 3d graphics because of concave self intersecting paths. Stroking a path can >>> be really hard because of thins such as tapering. >>> >>> The 3D hardware is designed to draw efficiently points, lines and >>> triangles. All of them are simple convex polygon. Most of the 2D vector >>> engines such as Cairo are software renderer, scanliners to be more >>> specific. The old cairo opengl backend had to tessellate the paths >>> >>> Later I am going to take a better look in Jun. And see how I can >>> integrate with Woden/Woden-Roassal. For what I have seen in the videos, it >>> seems to be using software rendering. Currently I have been working in my >>> internship about volumetric data visualization and the new FFI. >>> >>> 2014-12-30 11:01 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: >>> >>> Athens uses Cairo , Cairo can be used with OpenGL. You can use Cairo to >>>> apply a 2d vector graphic as a texture to a 3d polygon. Cairo website shows >>>> several examples of this. That means its possible to have 2d vector >>>> graphics in 3d space as if its true 3d. >>>> >>>> On Tue, Dec 30, 2014 at 12:10 AM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>>> Sven >>>>> >>>>> Jun is a 3D frameworks developed in 1998 in VisualWorks >>>>> http://aokilab.kyoto-su.ac.jp/jun/index.html >>>>> It was quite advanced and this is nice to get more people doing 3d in >>>>> Pharo. >>>>> They are using the back -end developed by ronie and JB and this is cool >>>>> >>>>> Athens is just a canvas and a oo decomposition of the canvas, brush >>>>> and strokes >>>>> nothing related to 3D. >>>>> Stef >>>>> >>>>> >>>>> Le 29/12/14 20:20, Sven Van Caekenberghe a Ã©crit : >>>>> >>>>> On 29 Dec 2014, at 15:36, stepharo <stepharo(a)free.fr> wrote: >>>>>>> >>>>>>> https://www.youtube.com/watch?v=sH_P5otiWJM&feature=youtu.be >>>>>>> >>>>>> It certainly looks nice, but what is Jun exactly ? >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >

Dec. 31, 2014

Re: [Pharo-dev] archives?

by Sven Van Caekenberghe

Also a good morning, not yet fully awake ? ;-) http://pharo.org/community http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/ > On 31 Dec 2014, at 11:13, stepharo <stepharo(a)free.fr> wrote: > > is this mailing-list archived? > Because I would like to browse it > Stef >

Dec. 31, 2014

Re: [Pharo-dev] Jun4Pharo so exciting :)

by stepharo

> Later I am going to take a better look in Jun. And see how I can > integrate with Woden/Woden-Roassal. For what I have seen in the > videos, it seems to be using software rendering. Currently I have been > working in my internship about volumetric data visualization and the > new FFI. Let us know your progress. From March I hope to get somebody to help you on FFI or before once SPur is out of the door. stef

Dec. 31, 2014

Re: [Pharo-dev] Jun4Pharo so exciting :)

by stepharo

Le 30/12/14 20:18, Ronie Salgado a Ã©crit : > > Athens uses Cairo , Cairo can be used with OpenGL. You can use > Cairo to apply a 2d vector graphic as a texture to a 3d polygon. > Cairo website shows several examples of this. That means its > possible to have 2d vector graphics in 3d space as if its true 3d. > > I do not think that is going to work easily with the best performance > possible. Cairo could be using OpenGL, but probably in a different > OpenGL than the one that is being used for 3d graphics. > > In addition, the Cairo OpenGL backend is experimental > (http://cairographics.org/OpenGL/) . Currently you have to render into > a surface in CPU, then transfer it into GPU and then render the > polygon. A naive version using the OpenGL backend is going to have > GPU->CPU->GPU roundtrip > > If we are using this route, I think that is better to just use the > current version of Athens for this. With Athens we can render into a > Form, which can be used to populate a Woden/Roassal texture or > transferred directly to OpenGL. This has the advantage of not having a > explicit dependency in Cairo. I guess that I will make a demo of this > later. It should be easy. > > I think that a longer term approach could be having a custom renderer, > tailored for Athens using OpenGL or maybe OpenCL. this would be nice :) > > 2D vector graphics are really hard. In my opinion they are harder than > 3d graphics because of concave self intersecting paths. Stroking a > path can be really hard because of thins such as tapering. > > The 3D hardware is designed to draw efficiently points, lines and > triangles. All of them are simple convex polygon. Most of the 2D > vector engines such as Cairo are software renderer, scanliners to be > more specific. The old cairo opengl backend had to tessellate the paths > > Later I am going to take a better look in Jun. And see how I can > integrate with Woden/Woden-Roassal. For what I have seen in the > videos, it seems to be using software rendering. Currently I have been > working in my internship about volumetric data visualization and the > new FFI. > > 2014-12-30 11:01 GMT-03:00 kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>>: > > Athens uses Cairo , Cairo can be used with OpenGL. You can use > Cairo to apply a 2d vector graphic as a texture to a 3d polygon. > Cairo website shows several examples of this. That means its > possible to have 2d vector graphics in 3d space as if its true 3d. > > On Tue, Dec 30, 2014 at 12:10 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Sven > > Jun is a 3D frameworks developed in 1998 in VisualWorks > http://aokilab.kyoto-su.ac.jp/jun/index.html > It was quite advanced and this is nice to get more people > doing 3d in Pharo. > They are using the back -end developed by ronie and JB and > this is cool > > Athens is just a canvas and a oo decomposition of the canvas, > brush and strokes > nothing related to 3D. > Stef > > > Le 29/12/14 20:20, Sven Van Caekenberghe a Ã©crit : > > On 29 Dec 2014, at 15:36, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > https://www.youtube.com/watch?v=sH_P5otiWJM&feature=youtu.be > > It certainly looks nice, but what is Jun exactly ? > > > > > >

Dec. 31, 2014

archives?

by stepharo

is this mailing-list archived? Because I would like to browse it Stef

Dec. 31, 2014

Re: [Pharo-dev] Smalltalk Reflections Podcast

by stepharo

Hi david > Craig Latta and I have started up a new weekly podcast called Smalltalk > Reflections. The web side is http://smalltalkreflections.blogspot.ca/ and > it's available from iTunes. We would like to ask the Pharo community if > anyone would be interested in participating to promote Smalltalk or Pharo. Yes definitively. > We'd love to be able to interview people from the Pharo community. Great idea. > Also if anyone would like to take on the task of recording a weekly Pharo insert > we'd love to have that as well. If weekly is too frequent for you, we can > also arrange monthly or whenever you have time. Weekly commitment is a hug commitment. > If you're interested in participating in any way, drop me a line at > david(a)simberon.com. I would be interested but I think that it would be nice to have other voices around pharo. I imagine that you know my blog http://www.pharoweekly.org I'm trying to keep the information I find there. Now let me know we could do once a month a short discussion around a topic. Stef > > Thanks > > > > -- > View this message in context: http://forum.world.st/Smalltalk-Reflections-Podcast-tp4797444.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Dec. 31, 2014

Re: [Pharo-dev] Smalltalk Reflections Podcast

by kilon alios

looks very interesting what you mean by "insert" ? On Tue, Dec 30, 2014 at 10:09 PM, davidbuck <david(a)simberon.com> wrote: > Craig Latta and I have started up a new weekly podcast called Smalltalk > Reflections. The web side is http://smalltalkreflections.blogspot.ca/ and > it's available from iTunes. We would like to ask the Pharo community if > anyone would be interested in participating to promote Smalltalk or Pharo. > We'd love to be able to interview people from the Pharo community. Also if > anyone would like to take on the task of recording a weekly Pharo insert > we'd love to have that as well. If weekly is too frequent for you, we can > also arrange monthly or whenever you have time. > > If you're interested in participating in any way, drop me a line at > david(a)simberon.com. > > Thanks > > > > -- > View this message in context: > http://forum.world.st/Smalltalk-Reflections-Podcast-tp4797444.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Dec. 31, 2014

Re: [Pharo-dev] Jun4Pharo so exciting :)

by Ronie Salgado

> > Is this a real concern ? Afterall vector data is a lot less complex than > 3d geometry and CPUs nowdays are multicore. For really smooth and complex animations, yes it is a concern. Performance. If the objective is to draw a static shape or a slow animation, it is not a big problem. Also CPU <-> GPU data transferring is an expensive operation that has to be avoided if possible. Actually 2D vector data is more complex. 3D geometry comes already processed to be directly rendered, and it is represented by only two arrays: vertices and indices. In contrast, 2D vector data is represented by a stream of commands that have to be evaluated. BTW, we don't have support for real multithreading in Pharo, and we will not have it for a very long time. The closest thing to real multithreading that we are getting in the near term > Don't know about the Opengl backend of Cairo. Igor also once shown me a > Spec for vector graphics on OpenGL by Khronos Group. > Well, there is OpenVG designed for mobile platform(Android and iOS). OpenVG is not supported by desktop graphic cards vendors. The closest thing we have in the desktop world is the NV_path_rendering NVIDIA only extension. At least the paper that describes this extension is really good. The bad thing is that it depends at least partially in the Loop-Blinn algorithm that is patented, if I remember right. Newest OpenGL versions also come with dynamic tesselation geometry shaders > that basically increase the detail of a 3d object the closer a camera gets > to it which is similar to vector graphics which is something that could > also work as basic via NBOpenGL to bring Athens to 3d side completely > bypassing Cairo. > In first place, not all of the world have at least DX11/OpenGL 4.xx level graphic card. But, it does not matter too much because the hardware tessellation does not help you anything with the main problem. The biggest problem is that 2D vector paths can be concave, and they can have a hole . The easiest way to support it is by using the stencil buffer, and in my opinion is the method with the better results. In fact, the NV_path_rendering extension is implemented in this way, but directly in the OpenGL driver. This method renders first the tessellated path with a triangle fan, with the stencil test set to invert the stencil buffer bits. In this way, the stencil buffer holds 1 in the points that are inside of the path, and 0 in the points that are outside of the path. Then, the bounding box of the path is covered with fill color/gradient, but with the stencil test set to only pass when the stencil buffer value is 1, and to also clear the stencil buffer in the covered region during the process to allow rendering more paths elements. Each one of the changes to the way the stencil buffer is used involves a state change, which is expensive. I think this is the reason of why NVIDIA implemented their extension directly in the OpenGL. I know of these problems because I implemented once the stencil method in C++ with OpenGL. The old opengl Cairo backend worked by triangulating the paths. Triangulation of concave geometry is hard to do, and there some degenerate case in which it produces bad results. Best regards Ronie 2014-12-30 16:58 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > Is this a real concern ? Afterall vector data is a lot less complex than > 3d geometry and CPUs nowdays are multicore. > > Don't know about the Opengl backend of Cairo. Igor also once shown me a > Spec for vector graphics on OpenGL by Khronos Group. > > So there are alternatives but as always it will require someone doing the > hard work to bring that functionality to Pharo. > > Newest OpenGL versions also come with dynamic tesselation geometry shaders > that basically increase the detail of a 3d object the closer a camera gets > to it which is similar to vector graphics which is something that could > also work as basic via NBOpenGL to bring Athens to 3d side completely > bypassing Cairo. > > On Tue, Dec 30, 2014 at 9:18 PM, Ronie Salgado <roniesalg(a)gmail.com> > wrote: > >> Athens uses Cairo , Cairo can be used with OpenGL. You can use Cairo to >>> apply a 2d vector graphic as a texture to a 3d polygon. Cairo website shows >>> several examples of this. That means its possible to have 2d vector >>> graphics in 3d space as if its true 3d. >>> >> I do not think that is going to work easily with the best performance >> possible. Cairo could be using OpenGL, but probably in a different OpenGL >> than the one that is being used for 3d graphics. >> >> In addition, the Cairo OpenGL backend is experimental ( >> http://cairographics.org/OpenGL/) . Currently you have to render into a >> surface in CPU, then transfer it into GPU and then render the polygon. A >> naive version using the OpenGL backend is going to have GPU->CPU->GPU >> roundtrip >> >> If we are using this route, I think that is better to just use the >> current version of Athens for this. With Athens we can render into a Form, >> which can be used to populate a Woden/Roassal texture or transferred >> directly to OpenGL. This has the advantage of not having a explicit >> dependency in Cairo. I guess that I will make a demo of this later. It >> should be easy. >> >> I think that a longer term approach could be having a custom renderer, >> tailored for Athens using OpenGL or maybe OpenCL. >> >> 2D vector graphics are really hard. In my opinion they are harder than 3d >> graphics because of concave self intersecting paths. Stroking a path can be >> really hard because of thins such as tapering. >> >> The 3D hardware is designed to draw efficiently points, lines and >> triangles. All of them are simple convex polygon. Most of the 2D vector >> engines such as Cairo are software renderer, scanliners to be more >> specific. The old cairo opengl backend had to tessellate the paths >> >> Later I am going to take a better look in Jun. And see how I can >> integrate with Woden/Woden-Roassal. For what I have seen in the videos, it >> seems to be using software rendering. Currently I have been working in my >> internship about volumetric data visualization and the new FFI. >> >> 2014-12-30 11:01 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: >> >> Athens uses Cairo , Cairo can be used with OpenGL. You can use Cairo to >>> apply a 2d vector graphic as a texture to a 3d polygon. Cairo website shows >>> several examples of this. That means its possible to have 2d vector >>> graphics in 3d space as if its true 3d. >>> >>> On Tue, Dec 30, 2014 at 12:10 AM, stepharo <stepharo(a)free.fr> wrote: >>> >>>> Sven >>>> >>>> Jun is a 3D frameworks developed in 1998 in VisualWorks >>>> http://aokilab.kyoto-su.ac.jp/jun/index.html >>>> It was quite advanced and this is nice to get more people doing 3d in >>>> Pharo. >>>> They are using the back -end developed by ronie and JB and this is cool >>>> >>>> Athens is just a canvas and a oo decomposition of the canvas, brush and >>>> strokes >>>> nothing related to 3D. >>>> Stef >>>> >>>> >>>> Le 29/12/14 20:20, Sven Van Caekenberghe a Ã©crit : >>>> >>>> On 29 Dec 2014, at 15:36, stepharo <stepharo(a)free.fr> wrote: >>>>>> >>>>>> https://www.youtube.com/watch?v=sH_P5otiWJM&feature=youtu.be >>>>>> >>>>> It certainly looks nice, but what is Jun exactly ? >>>>> >>>>> >>>>> >>>> >>>> >>> >> >

Dec. 30, 2014

Re: [Pharo-dev] A toast

by Tudor Girba

Nicely put, Esteban! Thank you everyone for making this happen. Anyone in the room not feeling energized?! :) Doru On Mon, Dec 29, 2014 at 1:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hello Pharoers, > > (sorry for the long post) > > I'm on holidays so I've been silent this latests days, but I didn't want > to let the opportunity goes to propose a toast :) > This year has been a great year (yeah, but not like those annoying > facebook cards), one year where we have worked itensively in the patient > consolidation of several lines of work. > This has been possible thanks to the great improvement that we have made > in the Pharo process itself, which required (and still requires) a massive > amount of effort: Since I arrived here (but not necessarily *because* I > arrived here: this is the work of everyone in Pharo community, I'm just > pointing to what I've seen and collaborated :P), we have changed a lot of > things: > > - we have deployed a solid CI infrastructure that can handle our > integration cycle without too much complications. Even if we still find > problems time to time, this has been an incredible step forward. > - thanks to this we have been able to change our release cycle from "it > happens when we believe is ready" to time-boxed releases, so we have > created Pharo 1.4, 2.0 and this year what, for me, is one of the most > complete and cool releases (up to now) that we have produced: Pharo 3.0. > - We have increased massively the amount of tests in the system (no sure > what is the percentage, but is high), so we have been able to change core > parts in the system without causing too much pain to developers (yeah, we > know there have been some errors some times, but well... "errare humanum > est", and I think we have learned from the process and now we do not make > same mistakes... in any case they are new mistakes :P). > - We have made huge steps in the "Pharo modularisation project", thanks to > the Pharo-minimal images and work we have started to move all into a > repeatable configuration (thanks to metacello and tools developed for this). > - We have also incorporated the VM building to this process and testing > cycle, so is a lot easier for everyone to build their own VM (if needed), > and for us we can be sure (as sure as possible at least) VM is in good > shape. > - We have improved documentation and release new books. People have > working a lot in a lot of cool and instructive videos that have moved our > "learning curve" several steps ahead. > > And this is just one part of the "invisible, ant work of everyday", in the > visible part, I will not bore (more than needed :P) with details about > previous releases, so I will just point some of the great things we have > made for the upcoming release, Pharo 4: > > - Thanks to GTools, we are slowly going to a better set of tools, with new > ways of see/handle old things. This is the most visible change this year > (and it has caused the most flamed wars, but well... we are a passionate > community). This release we have a new inspector, playground and spotter > (god, spotter is sooooo cool!), next release we hope to integrate a new > debugger and if planets align, a new Coder. > - We introduced OSWindow as a preview, a tool which will allow us to do a > lot of years waited features: start UI from image instead from VM > (transmiting to the used the decision of having one or not), multi-windows, > a vectorial UI instead the good-but-old bitblt we have now. > - We enhanced Athens and introduced the new TxModel. We still do now > achieve our objective of migrate our morphic drawing mechanism to athens, > but this is a lot of work and will take some time. > - We have improved a lot the development cycle with the introduction of > smart suggestions, the upcoming smart breakpoins and reflectivity. > - And of course, we have worked a lot in the cleaning of the system (an > invisible and ungrateful work, believe me) > > And this is just a glimpse, what I wrote this morning before breakfast, > wanting to thank all of you to let me be part of this super cool community, > and wanting to have a toast with you: > > For a 2015 with more stories, more adventures, more Pharo! > > Esteban > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 30, 2014