January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Athens/Morphic

by Aliaksei Syrel

Nice work, Nicolai! Brick does not work - It uses some of Canvas' private api, and it is > difficult to provide this with Athens. I will try to fix it when have time. Actually there was no need to use that private api, I just was too lazy to do slightly more math when converting global coordinates to local ones in drawing methods :) Cheers, Alex On Fri, Jan 23, 2015 at 5:40 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-01-10 13:18 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > >> >> I think I got the MorphTreeTransformMorph now working, need to clean up >> the code >> and maybe I 'll upload this to the athens repository. >> >> nicolai >> >> >> > > I don't know how often I thought "I got this working", but NOW I think I > got this morphic transformation working :) > > I give up to use the AthensTextRenderer classes, they aren't implemented > fully, to much work for me to do this. > Instead, I just subclass the DisplayScanner and reimplemented all > Canvas-draw-methods with athens-drawing-methods. > > Still some morphs aren't "ported", but they use some magic. For example, > for some morphs the drawOn:Canvas methods > calls many other methods drawBackroundOn: aCanvas, drawIconOn: aCanvas, > drawLinesOn: ... > (for exampe: IndentingListItemMorph, MorphTreeMorph). Porting this morphs > means, we have to duplicate all this methods. > (Ok there are other options, but I don't want to change something in the > original Morphic/Canvas workflow). > Other Morphs just delegate the drawing call, that delegate the calls > further and deep in this call change the > drawing actually happens. This again means I have to duplicate all this > methods just to use an AthensCanvas for drawing. > > So, for those Morphs I use a Canvas Wrapper (AthensCanvasWrapper). I > already wrote about this one, it implements (most) > of the Morphic/Canvas API on top of Athens, it was an alternative approach > for Morphic<->Athens porting. This one is > now a much more advanced version and I can use it in combination with the > other drawOnAthensCanvas methods. > > The drawOnAthensCanvas method in MorphTreeNodeMorph for example just calls > this > drawOnAthensCanvas: anAthensCanvas > self drawOnCanvasWrapperFor: anAthensCanvas > which in turn creates an AthensCanvasWrapper and then calls > self drawOn: wrapper > The same Morphic/Canvas drawOn method is used! But the rendering is done > with Athens. > > Rubric does not work - Itself already duplicates many code, I don't want > to look at this now. > Brick does not work - It uses some of Canvas' private api, and it is > difficult to provide this with Athens. > > > Many other things are working, > PLEASE try it out. Morphic on Athens looks great (except the font issue > ...). > > Just take a fresh image (I use 40442) and load the attached > > morphic_on_athens.cs (<-- all code for Morphic<->Athens porting) > athens_test_display.3.cs (<-- Tests Athens for the whole MorphicWorld) > > Open a Workspace (old workspace preferred) and execute > > AthensTestDisplay testSwitchToAthensFor: 25. > > This will switch the world display rendering for 25 seconds from Morphics > Canvas-Api to > Athens. > > > Feedback welcome. > > > > > > > >

Jan. 23, 2015

Re: [Pharo-dev] [Ann] a short Bloc demo

by Nicolai Hess

2014-12-25 11:33 GMT+01:00 Alain Plantec <alain.plantec(a)yahoo.com>: > > > On 25 Dec 2014, at 10:31, stepharo <stepharo(a)free.fr> wrote: > > > > > > Le 25/12/14 03:04, Ben Coman a Ã©crit : > >> Really nice to see your progress. Now do you have some sketches that > show how it relates to the components of the existing Morphic? What is > being disposed of, what reimplemented, what ported? > > yes, almost everything is new or rewritten and you are right, its time to > write documentation. > Now, there is one well identified issue. > Athens is used to render everything except > the Morphic world. > This is cool but at the end of the rendering, the vm Form based display is > used by wrappers : > see in TBlAthensWrapper>>unprotectedFullDrawOn: > ---- > self surface displayOnMorphicCanvas: aCanvas at: self position > ââ > It slows down the rendering very much. > what would be cool would be to have a native Athens/Cairo vm display to > really > benefit from Athens. > > Really? This just calls copyBits from the surface plugin. Although it calls AthensCairoSurface>>#asForm, there is no "real" Form involved. I can do a full MorphicWorld drawing on top of Athens and it is quite fast. I did some experiments with the direct use of the window context (on Win32: cairo_win32_surface_create) <http://www.cairographics.org/manual/cairo-Win32-Surfaces.html#cairo-win32-s…> But with this surface, we can not access the form data anymore, something like Form>>#copy: does not work, or I didn't found out how. nicolai

Jan. 23, 2015

Re: [Pharo-dev] Package cleaning

by Ben Coman

On Fri, Jan 23, 2015 at 8:00 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Marcus, Ben and others, > > how can we proceed on META issue https://pharo.fogbugz.com/f/cases/14447? > > Anyone with deeper knowdlege of Monticello and the integration process > able to help here? It's a merging issue although nothing to merge. > > Thx > T. > > Actually, I discovered that the problem only occurs when you wrap the package in a slice. Given that these will be isolated single package updates, without needing to synchronise with other packages, would it be possible & pragmatic to load the packages directly without a slice, to get the issues out of the way. Or maybe a script that does the rename and then pushes the dirty packages to the repository? Now do we need to be concerned with the oldnamed package being an ancestor of the renamed ? cheers -ben

Jan. 23, 2015

Re: [Pharo-dev] Updated Pharo by Example SUnit chapter

by Ben Coman

Hi Daniel, You volunteered in another thread to review the PBE updates. I'm not sure where its currently up to. I guess from the post I'm responding to that its done up to the SUnit chapter. The work is being done here... https://github.com/SquareBracketAssociates/UpdatedPharoByExample with the overall PDF here... https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/lastSucces… cheers -ben On Mon, Dec 29, 2014 at 6:00 AM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I'm slowly converting Pharo by example to Pharo 40 and pillar. > Here is the SUnit chapter. > If you have feedback the chapter is on github. > > Stef >

Jan. 23, 2015

Re: [Pharo-dev] Athens/Morphic

by Nicolai Hess

2015-01-10 13:18 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > > I think I got the MorphTreeTransformMorph now working, need to clean up > the code > and maybe I 'll upload this to the athens repository. > > nicolai > > > I don't know how often I thought "I got this working", but NOW I think I got this morphic transformation working :) I give up to use the AthensTextRenderer classes, they aren't implemented fully, to much work for me to do this. Instead, I just subclass the DisplayScanner and reimplemented all Canvas-draw-methods with athens-drawing-methods. Still some morphs aren't "ported", but they use some magic. For example, for some morphs the drawOn:Canvas methods calls many other methods drawBackroundOn: aCanvas, drawIconOn: aCanvas, drawLinesOn: ... (for exampe: IndentingListItemMorph, MorphTreeMorph). Porting this morphs means, we have to duplicate all this methods. (Ok there are other options, but I don't want to change something in the original Morphic/Canvas workflow). Other Morphs just delegate the drawing call, that delegate the calls further and deep in this call change the drawing actually happens. This again means I have to duplicate all this methods just to use an AthensCanvas for drawing. So, for those Morphs I use a Canvas Wrapper (AthensCanvasWrapper). I already wrote about this one, it implements (most) of the Morphic/Canvas API on top of Athens, it was an alternative approach for Morphic<->Athens porting. This one is now a much more advanced version and I can use it in combination with the other drawOnAthensCanvas methods. The drawOnAthensCanvas method in MorphTreeNodeMorph for example just calls this drawOnAthensCanvas: anAthensCanvas self drawOnCanvasWrapperFor: anAthensCanvas which in turn creates an AthensCanvasWrapper and then calls self drawOn: wrapper The same Morphic/Canvas drawOn method is used! But the rendering is done with Athens. Rubric does not work - Itself already duplicates many code, I don't want to look at this now. Brick does not work - It uses some of Canvas' private api, and it is difficult to provide this with Athens. Many other things are working, PLEASE try it out. Morphic on Athens looks great (except the font issue ...). Just take a fresh image (I use 40442) and load the attached morphic_on_athens.cs (<-- all code for Morphic<->Athens porting) athens_test_display.3.cs (<-- Tests Athens for the whole MorphicWorld) Open a Workspace (old workspace preferred) and execute AthensTestDisplay testSwitchToAthensFor: 25. This will switch the world display rendering for 25 seconds from Morphics Canvas-Api to Athens. Feedback welcome.

Jan. 23, 2015

Nautilus architectural query wrt monticello announcements

by Ben Coman

I was looking to https://pharo.fogbugz.com/default.asp?14616 per the other "Package Cleaning" thread and noticed that... PackageTreeNautilusUI(AbstractNautilusUI)>>mcWorkingCopyCreated: ...responds to Monticello /MCWorkingCopyCreated/ announcements to create packages using use RPackageOrganizer, and I wonder if its really a good idea for a UI component to be doing that. What happens if that UI component is replaced? It seems to me that the UI should listen only for announcements from the default RPackageOrganiser, which in turn is the entity that acts on announcements from Monticello. cheers -ben

Jan. 23, 2015

Re: [Pharo-dev] GTools regression

by Andrei Chis

On Fri, Jan 23, 2015 at 3:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > GLMThemeIcons was refactored (by me) to move out the icons from there (and > included in ThemeIcons)â¦ so they can be themed with icon packs. > Also I made them compatible with the eclipse pack (while preserving those > icons). > I sent to you those changes last month (or the previous, I do not > remember). > Now, in last Pharo4 build, the class GLMThemeIcons again has the icons > there (and because of that, playground and inspector are shown glamour > iconsâ¦ which is incorrect for Pharo4) > Aha. Thanks for the explanation :) Your changes were integrated but got then reverted :( It's fixed now in the latest moose version Cheers, Andrei > > Esteban > > On 23 Jan 2015, at 14:58, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > What do you mean that the GLMThemeIcons are restored? > > > Cheers, > Andrei > > On Fri, Jan 23, 2015 at 2:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi, >> >> Someway the old GLMThemeIcons is restored (which means icons are wrong) >> (sending to moose-dev too, but I donât know if needed :P) >> >> Esteban >> > > >

Jan. 23, 2015

Re: [Pharo-dev] GTools regression

by Esteban Lorenzano

GLMThemeIcons was refactored (by me) to move out the icons from there (and included in ThemeIcons)â¦ so they can be themed with icon packs. Also I made them compatible with the eclipse pack (while preserving those icons). I sent to you those changes last month (or the previous, I do not remember). Now, in last Pharo4 build, the class GLMThemeIcons again has the icons there (and because of that, playground and inspector are shown glamour iconsâ¦ which is incorrect for Pharo4) Esteban > On 23 Jan 2015, at 14:58, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > What do you mean that the GLMThemeIcons are restored? > > > Cheers, > Andrei > > On Fri, Jan 23, 2015 at 2:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi, > > Someway the old GLMThemeIcons is restored (which means icons are wrong) > (sending to moose-dev too, but I donât know if needed :P) > > Esteban >

Jan. 23, 2015

Re: [Pharo-dev] GTools regression

by Andrei Chis

What do you mean that the GLMThemeIcons are restored? Cheers, Andrei On Fri, Jan 23, 2015 at 2:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Someway the old GLMThemeIcons is restored (which means icons are wrong) > (sending to moose-dev too, but I donât know if needed :P) > > Esteban >

Jan. 23, 2015

GTools regression

by Esteban Lorenzano

Hi, Someway the old GLMThemeIcons is restored (which means icons are wrong) (sending to moose-dev too, but I donât know if needed :P) Esteban

Jan. 23, 2015