February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Bloc] MDLColor and new gradient

by Aliaksei Syrel

We will come back to theme, style, colors later. Much later. On Feb 24, 2016 5:16 PM, "stepharo" <stepharo(a)free.fr> wrote: > I do not know. > May be. > > Le 23/2/16 10:30, Denis Kudriashov a Ã©crit : > > Hi > > 2016-02-23 9:13 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> May be we should have some Palette >> >> And we could have (brainstorming) >> >> (ColorBuilder from: MDLPalette) >> -> aColorBuilder >> aColorBuilder red >> -> .... >> > > What the difference between red colors from different palettes? And why it > is not just "MDLPalette red"? > > >

Feb. 25, 2016

Re: [Pharo-dev] [Bloc] stroke width and layout measure

by Aliaksei Syrel

I did not finish with shape yet. For arbitrary path it is not possible in cairo to render stroke inside (really inside) of the shape and take stroke into account to render children. Such behavior to some extent can be simulated but it really complicates things. So I want to add in contract that it is responsibility of developer to take border into account. cheers On Feb 24, 2016 1:07 PM, "Glenn CavarlÃ©" <glenn(a)cavarle.fr> wrote: > Hi, > > The stroke width of an element's shape is not taken into account when the > child elements are measured. > In fact, a child element that matches parent extent hides the left and top > borders of its parent. > Will it mandatory to use a padding to fix that ? Or is it just part of the > work that still to be done ? > > Regards, > > > > ----- > Glenn CavarlÃ© > -- > View this message in context: > http://forum.world.st/Bloc-stroke-width-and-layout-measure-tp4880292.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Feb. 25, 2016

Re: [Pharo-dev] [bloc] why redefining new is not enough?

by Stephan Eggermont

On 25-02-16 12:31, Alain Plantec via Pharo-dev wrote: >the space may be needed during #initialize. I would strongly advice against that. That makes it untestable Stephan

Feb. 25, 2016

Re: [Pharo-dev] [Moose-dev] Call for action for Roassal

by Alexandre Bergel

Do you have an example? I am not sure to understand. Alexandre > On Feb 25, 2016, at 12:40 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > This is very cool. We will all benefit from this documentation. > > One thing that I would still like to see fixed before the release is the edge building (this problem of not being able to properly specify random objects to be taken into account when building edges). Could we work on that? > > Cheers, > Doru > > >> On Feb 24, 2016, at 9:51 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> Dear community, >> >> As you may have seen, Roassal has entered a stabilization phase. The book AgileVisualization.com will soon be released. After its release, Roassal will go over a new development phase. In order to prepare it, I am asking this question: >> >> What are the 3 aspects you would like to see improved in Roassal? >> >> You can answer publicly or by sending private messages. >> >> Kind regards, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > www.feenk.com > > âLive like you mean it." > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 25, 2016

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

by stepharo

To me this is pre optimisation I do not see why we cannot do BlElement>>drawOnAthensCanvas: aCanvas self shape drawOnAthensCanvas: aCanvas with: self so far only localBounds from BlElement are used. And to me this is really strange to have an object responsible for the drawing not doing it. It blurs the responsibility. Stef Le 25/2/16 10:39, Tudor Girba a Ã©crit : > Hi, > > Good question. > > The reason we want to have the morph be responsible because subclasses might decide to draw in a different way regardless of the shape being used. This gives us the maximum freedom for more specific blocs. Still, this is something to experiment with once we have more complicated examples built with Bloc. > > Cheers, > Doru > > >> On Feb 25, 2016, at 9:56 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi Blockers >> >> I do not really understand why drawOnAthensCanvas: is not defined on BlShape >> (especially when we see how many self space are defined in this method. >> And this is one of the few things I thought I understood from bloc (grouping the rendering in a separate object). >> >> >> drawOnAthensCanvas: aCanvas >> "Actually render receiver on aCanvas in local bounds. >> Override to customize. >> aCanvas is an instance of AthensCanvas >> aCanvas must not be nil" >> >> | pathTransform | >> pathTransform := aCanvas pathTransform. >> "First we fill" >> pathTransform >> restoreAfter: >> [ | path fillExtent fillTranslation | >> "We fill inside natural element's bounds" >> fillExtent := self shape path fillExtentFor: self shape inBounds: self localBounds. >> path := self shape path pathOn: aCanvas forExtent: fillExtent. >> "Translate fill if needed" >> fillTranslation := self shape path >> fillTranslationFor: self shape >> inBounds: self localBounds. >> pathTransform translateBy: fillTranslation. >> aCanvas >> setPaint: self shape fillPaint; >> drawShape: path ]. >> pathTransform >> restoreAfter: >> [ | path strokeExtent strokeTranslation | >> "We stroke inside natural element's bounds" >> strokeExtent := self shape path strokeExtentFor: self shape inBounds: self localBounds. >> path := self shape path pathOn: aCanvas forExtent: strokeExtent. >> "Translate stroke if needed" >> strokeTranslation := self shape path >> strokeTranslationFor: self shape >> inBounds: self localBounds. >> pathTransform translateBy: strokeTranslation. >> aCanvas >> setPaint: self shape strokePaint; >> drawShape: path ] >> > -- > www.tudorgirba.com > www.feenk.com > > "Sometimes the best solution is not the best solution." > > >

Feb. 25, 2016

Is there a plan to have refreshing values in debugger?

by stepharo

Hi Is there a plan to have refreshed values (instance variables) in debugger and inspector? This is super annoying to have to refresh the complete list in the debugger to see new values of instance variables. Why we cannot put back the old pulling behavior and in the future use reflectivity? Stef

Feb. 25, 2016

Re: [Pharo-dev] [Moose-dev] Call for action for Roassal

by Tudor Girba

This is very cool. We will all benefit from this documentation. One thing that I would still like to see fixed before the release is the edge building (this problem of not being able to properly specify random objects to be taken into account when building edges). Could we work on that? Cheers, Doru > On Feb 24, 2016, at 9:51 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Dear community, > > As you may have seen, Roassal has entered a stabilization phase. The book AgileVisualization.com will soon be released. After its release, Roassal will go over a new development phase. In order to prepare it, I am asking this question: > > What are the 3 aspects you would like to see improved in Roassal? > > You can answer publicly or by sending private messages. > > Kind regards, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com âLive like you mean it."

Feb. 25, 2016

Re: [Pharo-dev] [bloc] why redefining new is not enough?

by Alain Plantec

> On 25 fÃ©vr. 2016, at 11:49, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > this is badâ¦ redefining basicNew should not be done, never, never, never. why ? > thatâs why we have new and basicNew :) the space may be needed during #initialize. this is why the initialization of the space is done in basicNew. But ok, we will fix that. Thanks Alain > > Esteban > >> On 25 Feb 2016, at 09:52, stepharo <stepharo(a)free.fr> wrote: >> >> BlElement class>>basicNew >> "Redefined to set the space of the element" >> >> ^ super basicNew basicSpace: BlUniverse default runningSpace >> >> why redefining new is not enough? >> >> Ok now back to the mooc videos :( >> >> > >

Feb. 25, 2016

debugger versus primitive 19 "simulation guard"

by Ben Coman

Trying to debug step two times into... [ 'a' ] newProcess ...hangs the image. It works okay with... Pharo5.0 update: #50495 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 Unix built on Apr 2 2015 00:51:53 Compiler: 4.6.3 but not with... Pharo5.0 update: #50496 CoInterpreter VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 Unix built on Jan 14 2016 11:50:34 Compiler: 4.6.3 btw, the same case on Squeak-4.6-All-In-one and Squeak-5-All-In-One both produce "Code simulation error." Is it maybe related to... "another endless debugger loop" https://pharo.fogbugz.com/default.asp?16877 cheers -ben

Feb. 25, 2016

Re: [Pharo-dev] [bloc] why redefining new is not enough?

by Esteban Lorenzano

this is badâ¦ redefining basicNew should not be done, never, never, never. thatâs why we have new and basicNew :) Esteban > On 25 Feb 2016, at 09:52, stepharo <stepharo(a)free.fr> wrote: > > BlElement class>>basicNew > "Redefined to set the space of the element" > > ^ super basicNew basicSpace: BlUniverse default runningSpace > > why redefining new is not enough? > > Ok now back to the mooc videos :( > >

Feb. 25, 2016