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

Re: [Pharo-dev] GSoC alternative: SOCIS

by Yuriy Tymchuk

Looks interesting. But then we need someone to âsellâ pharo as a space-related OS projectâ¦ I mean, itâs not hard, just talk about remote debugging and live update (project of Max Mattone). But someone has to do it. And also someone has to propose the projects around this topics. Cheers. Uko > On 02 Apr 2016, at 19:23, Skip <skippetie(a)gmail.com> wrote: > > Hi everyone, > > I just came across an alternative to GSoC called SOCIS. > It's run by the ESA (European Space Agency): > > http://sophia.estec.esa.int/socis/ <http://sophia.estec.esa.int/socis/> > > Maybe you can try applying there? Deadline is April 10th. > > And maybe you all know already about this, in that case feel free to let this thread die :) > > Best wishes, > > Skip

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

On 3 April 2016 at 12:08, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > If you want to change clicking behaviour you need to override one single > method. > it is not about just clicking behavior. Sure i can override every single method to get behavior i want, at any point in system i need. Then what is purpose of making any design, if it all goes down to 'oh.. if you don't like something , just go and do it youself'? Seriously? > Everything you wrote with unreadable amount of characters is for nothing. > > Haha.. If you can't read something, it does not means, that there's nothing. It just you cannot read. > All mentioned stuff is possible. > Details, that statement requires. You seem don't want to demonstrate that your concept is sound. Because i wanna see how it goes.. So far i have doubts about it, which i tried to formulate in previous posts.. i may not understand in it something, something you understand.. and i wanna see where i wrong. And in response i got nothing, no arguments, zero. This is exactly, what called 'nothing'. > On Apr 3, 2016 10:30 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: > >> >> >> On 3 April 2016 at 10:18, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi Igor, >>> >>> Thanks for this nice description :). >>> >>> Indeed, the Shape in Bloc is primarily a clipping shape that knows how >>> to draw the path around and to fill itself. Of course, it also handles the >>> interaction. >>> >>> When you want to have a composition, you are encouraged to create >>> multiple elements (morphs). This is a way to handle both more complicated >>> interaction and more complicated drawing. Of course, you can still override >>> the drawing method and draw whatever you want on it, but we would rather >>> have a simple composition. >>> >>> The disadvantage of this design is that indeed, is that it is not >>> sophisticated. The advantage of this design is that it is not sophisticated >>> :) and you get only one tree of compositions for the elements without >>> another level of composition at the shape level. The main reason we went >>> this route is because we want Bloc to pose as little constraints for the >>> things built on top as possible without losing power. >>> >>> Does this make sense for you? >>> >> >> It makes sense, sure thing. >> But it does not solves the problem. >> As i explained before, a single shape cannot serve as both clipping, UI >> handling and drawing all together. Because it is three separate roles, >> which is good if they coincide, but causing a lot of problems, when they >> are not. >> It is not matters how you compose or decompose shapes.. there is simply >> no composition which can turn rectangle into, lets say circle. >> it simply impossible to construct required clipping shape, or UI shape >> from set of drawing shapes, in case when they are completely different from >> each other. >> >> For instance if i want morph with rectangular appearance (rectangle >> shape) to respond on clicks only within circular subregion inside that >> rectangle, i will be forced to create a submorph and then rewire event >> handling back to its parent. And that happens every time i need a different >> shape for mouse clicks than shape for drawing. Now add clipping here... and >> you will get a nightmare of bells and whistles, composing and whatsnot. >> >> As for 'sophisticated'.. let see: >> so, in my proposition, i do: >> - draw rectangle and circle inside >> - define that circle as UI shape >> - define that rectangle as clipping shape >> done. >> In your design, i have to: >> - make a morph with rectangular shape >> - create submorph with circular shape >> - wire clicking of a submorph to propagate event to its parent >> >> or think about some kind of composition.. composing what with what? >> does it union of circle and rectangle? or intersection? depending the way >> how you composing those two shapes you receive one or another outcome.. >> and that event wiring is extra work.. >> So, it may look that what i proposing is more sophisticated.. >> But i just wanna see a separate roles taking own places, nothing else. >> I do not inventing new concepts, that wasn't there before: >> - you need clipping, >> - you need drawing >> - you need UI handling >> >> You see, it is not a framework, that forcing you to be 'sophisticated' .. >> it is domain itself. It draws a clear border between things that are >> optional and things that are absolutely necessary, since they are separate >> concepts and roles. >> >> You simply cannot represent an infinite dimension of drawing compositions >> by a composition of UI elements. Only the simplest cases.. >> It is big mistake to imply that anything that you drawing on screen must >> be a full-blown UI element (which is morph is) or their composition. >> It makes you quite limited in terms of what you can draw and what not. >> Morph is UI building brick.. but it is not graphical building brick.. >> making such parallel gives more troubles than it solves. >> >> To me concept where morph==shape==clipping shape==ui shape is just: >> - you can have bike of any color, as long as it's black. >> >> Can you enlighten me, what composition of black bikes can result in a >> green one? >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> > On Apr 3, 2016, at 6:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> > >>> > Oh, yeah.. i missed one more kind of shape, you may want to introduce: >>> > - clipping shape. >>> > >>> > For optimizing drawing operations, you may want to define a region, >>> which guarantees, that anything you paint, nothing outside defined region >>> will affect the screen. Because else, you will allow morph to render >>> anywhere and therefore, it is really hard for UI subsystem to account >>> damage on the screen. >>> > But once you define such shape, then you can clearly tell, which >>> portion of the screen may or may not be damaged and therefore act >>> accordingly. >>> > >>> > So, overall when we talking about shapes, we need to talk about three >>> different kinds of them: >>> > >>> > - UI interaction shape >>> > - clipping shape >>> > - shape(s) used to draw >>> > >>> > those three may or may not coincide into single one, depending on >>> complexity and what you wanna do.. >>> > But they can be completely different from each other and in order to >>> avoid confusion and frustration, i would really introduce them in such >>> manner, that users have clear vision on what happens with their morphs and >>> how to achieve what they want. >>> > >>> > Clearly, a single #shape: is not enough, if you want a non-conflicting >>> representation of these concepts in UI. >>> > >>> > >>> > On 3 April 2016 at 07:15, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> > >>> > >>> > On 2 April 2016 at 20:59, stepharo <stepharo(a)free.fr> wrote: >>> > >>> > >>> > Le 2/4/16 17:31, Aliaksei Syrel a Ã©crit : >>> >> You don't want to draw a shape, you configure it. Shape can not be >>> drawn, it is not an AthensPath. >>> >> >>> >> cell shape: (BlShape new >>> >> path: BlCirclePath new; >>> >> strokePaint: (BlStrokePaint new >>> >> paint: Color blue; >>> >> width: 1)). >>> >> cell extent: 50@50. >>> >> >>> > >>> > But this is not what I want! As I mentioned in a mail that was sent >>> but never arrived. >>> > I want a square and this is why I did >>> > >>> > BlCell>>initialize >>> > super initialize. >>> > self >>> > shape: >>> > (BlShape new >>> > fillPaint: (BlColorPaint new color: (Color yellow)); >>> > path: BlRectanglePath new); >>> > extent: self extent >>> > >>> > >>> > then I want to draw something extra this is why I overrode >>> drawOnAthensCanvas: aCanvas >>> > >>> > Now I stop but I find bloc too complex. >>> > >>> > Sorry but I cannot lose time like that and just get frustrated at the >>> end. >>> > I will use the athens canvas directly and stay in morph for now. >>> > >>> > >>> > I think there's a bit of misconception. >>> > In Athens, shape representing any area you wanna fill with paint. >>> Period. >>> > It can be of any complexity, self-intersecting yadda yadda.. the main >>> point is that it defines a region(s), that going to be filled with chosen >>> paint during draw operation. >>> > From perspective of morphs, as UI elements, most of them require some >>> shape(s) to represent themselves on the screen. But there are morphs, that >>> while still taking part in UI, don't need any shapes since they never drawn >>> on the screen. >>> > Another point is that nowhere said that morph can be represented by a >>> one and only one shape period. Because as in your case, you want to, say, >>> draw rectangle with paint A, and circle with paint B, then you basically >>> need two different shapes (overlapping or not - not really matters) to >>> represent morph on the screen. >>> > >>> > So, the first point in misconception comes from 'self shape:'.. >>> > It is wrong from that perspective, because it is all fine, when morph >>> using only single shape to represent itself.. but when you need multiple >>> shapes, you are in trouble. It at least misleading, because provoking you >>> to think that there can be only one. >>> > >>> > Then you need to invent a 'composite shape' that basically a >>> collection of shapes for a single morph, that will represent it on the >>> screen. >>> > >>> > A tangent to that, is that since most of morphs has mostly static >>> geometry/topology and changing it very rarely and much less often comparing >>> to drawing same shape(s) over and over again, it is right thing to define >>> and initialize shape(s) and reuse them later in #draw method. Since you >>> don't change shape(s), you don't have to generate new object(s). >>> > From that perspective, this is nice, resource saving, approach. >>> > But let us not forget, that this is just a 'statistical observation' >>> and hence good to be a default setup. But it should not dictate you the >>> rule(s). >>> > You should still be able to define shape(s) on the fly or change it on >>> the fly, dynamically. >>> > >>> > Another problematic is that you may want to use different shapes for >>> > a) painting morph on screen >>> > b) defining geometry of the morph for UI interactions. >>> > As an example, let say, you want a rectangle with circle in centre on >>> the screen, but also want morph to react on mouse over/clicks only if mouse >>> cursor is inside a circle, but not when it's over an area covered by >>> rectangle. >>> > >>> > What it means, that from UI perspective, you want from morph to define >>> its shape, lets call it 'UI interaction shape'.. and from that perspective >>> 'self shape:' is a good choice. But as example says, it has nothing to do >>> with 'drawing shape(s)', which may or may not coincide with shape you using >>> for UI interaction(s). >>> > >>> > Because it defines an area, where UI stuff could happen. And indeed, >>> you really need one, and only one. You don't need multiple shapes there, >>> since it serves to answer a simple question: 'are my mouse in interesting >>> region or not'?. >>> > Like in your case, when you having box with circle inside , which is >>> two shapes, but only one shape that can define an interesting region, it >>> could be: >>> > - intersection of >>> > - union >>> > - subtraction >>> > >>> > And that could be completely different from shape(s) you may need to >>> draw it on the screen. >>> > >>> > Stef >>> > >>> >> On Apr 2, 2016 4:57 PM, "stepharo" <stepharo(a)free.fr> wrote: >>> >> Hi >>> >> >>> >> I want a square morph with a circle or a line at 45 degree inside >>> >> Now I do not get it. >>> >> >>> >> I thought that I needed to specialize drawOnAthensCanvas: so I did >>> >> >>> >> BlCell >> drawOnAthensCanvas: aCanvas >>> >> >>> >> super drawOnAthensCanvas: aCanvas. >>> >> aCanvas >>> >> drawShape: (BlShape new >>> >> strokePaint: >>> >> (BlStrokePaint new >>> >> paint: (BlColorPaint new >>> color: (Color blue)); >>> >> width: 15); >>> >> path: BlCirclePath new). >>> >> >>> >> Now I do not know how I can specify a shape size >>> >> >>> >> So I will use another API than drawShape: >>> >> >>> >> Stef >>> >> >>> > >>> > >>> > >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> > >>> > >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Reasonable is what we are accustomed with." >>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Aliaksei Syrel

If you want to change clicking behaviour you need to override one single method. Everything you wrote with unreadable amount of characters is for nothing. All mentioned stuff is possible. On Apr 3, 2016 10:30 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: > > > On 3 April 2016 at 10:18, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Igor, >> >> Thanks for this nice description :). >> >> Indeed, the Shape in Bloc is primarily a clipping shape that knows how to >> draw the path around and to fill itself. Of course, it also handles the >> interaction. >> >> When you want to have a composition, you are encouraged to create >> multiple elements (morphs). This is a way to handle both more complicated >> interaction and more complicated drawing. Of course, you can still override >> the drawing method and draw whatever you want on it, but we would rather >> have a simple composition. >> >> The disadvantage of this design is that indeed, is that it is not >> sophisticated. The advantage of this design is that it is not sophisticated >> :) and you get only one tree of compositions for the elements without >> another level of composition at the shape level. The main reason we went >> this route is because we want Bloc to pose as little constraints for the >> things built on top as possible without losing power. >> >> Does this make sense for you? >> > > It makes sense, sure thing. > But it does not solves the problem. > As i explained before, a single shape cannot serve as both clipping, UI > handling and drawing all together. Because it is three separate roles, > which is good if they coincide, but causing a lot of problems, when they > are not. > It is not matters how you compose or decompose shapes.. there is simply no > composition which can turn rectangle into, lets say circle. > it simply impossible to construct required clipping shape, or UI shape > from set of drawing shapes, in case when they are completely different from > each other. > > For instance if i want morph with rectangular appearance (rectangle shape) > to respond on clicks only within circular subregion inside that rectangle, > i will be forced to create a submorph and then rewire event handling back > to its parent. And that happens every time i need a different shape for > mouse clicks than shape for drawing. Now add clipping here... and you will > get a nightmare of bells and whistles, composing and whatsnot. > > As for 'sophisticated'.. let see: > so, in my proposition, i do: > - draw rectangle and circle inside > - define that circle as UI shape > - define that rectangle as clipping shape > done. > In your design, i have to: > - make a morph with rectangular shape > - create submorph with circular shape > - wire clicking of a submorph to propagate event to its parent > > or think about some kind of composition.. composing what with what? > does it union of circle and rectangle? or intersection? depending the way > how you composing those two shapes you receive one or another outcome.. > and that event wiring is extra work.. > So, it may look that what i proposing is more sophisticated.. > But i just wanna see a separate roles taking own places, nothing else. > I do not inventing new concepts, that wasn't there before: > - you need clipping, > - you need drawing > - you need UI handling > > You see, it is not a framework, that forcing you to be 'sophisticated' .. > it is domain itself. It draws a clear border between things that are > optional and things that are absolutely necessary, since they are separate > concepts and roles. > > You simply cannot represent an infinite dimension of drawing compositions > by a composition of UI elements. Only the simplest cases.. > It is big mistake to imply that anything that you drawing on screen must > be a full-blown UI element (which is morph is) or their composition. > It makes you quite limited in terms of what you can draw and what not. > Morph is UI building brick.. but it is not graphical building brick.. > making such parallel gives more troubles than it solves. > > To me concept where morph==shape==clipping shape==ui shape is just: > - you can have bike of any color, as long as it's black. > > Can you enlighten me, what composition of black bikes can result in a > green one? > > >> >> Cheers, >> Doru >> >> >> > On Apr 3, 2016, at 6:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > >> > Oh, yeah.. i missed one more kind of shape, you may want to introduce: >> > - clipping shape. >> > >> > For optimizing drawing operations, you may want to define a region, >> which guarantees, that anything you paint, nothing outside defined region >> will affect the screen. Because else, you will allow morph to render >> anywhere and therefore, it is really hard for UI subsystem to account >> damage on the screen. >> > But once you define such shape, then you can clearly tell, which >> portion of the screen may or may not be damaged and therefore act >> accordingly. >> > >> > So, overall when we talking about shapes, we need to talk about three >> different kinds of them: >> > >> > - UI interaction shape >> > - clipping shape >> > - shape(s) used to draw >> > >> > those three may or may not coincide into single one, depending on >> complexity and what you wanna do.. >> > But they can be completely different from each other and in order to >> avoid confusion and frustration, i would really introduce them in such >> manner, that users have clear vision on what happens with their morphs and >> how to achieve what they want. >> > >> > Clearly, a single #shape: is not enough, if you want a non-conflicting >> representation of these concepts in UI. >> > >> > >> > On 3 April 2016 at 07:15, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > >> > >> > On 2 April 2016 at 20:59, stepharo <stepharo(a)free.fr> wrote: >> > >> > >> > Le 2/4/16 17:31, Aliaksei Syrel a Ã©crit : >> >> You don't want to draw a shape, you configure it. Shape can not be >> drawn, it is not an AthensPath. >> >> >> >> cell shape: (BlShape new >> >> path: BlCirclePath new; >> >> strokePaint: (BlStrokePaint new >> >> paint: Color blue; >> >> width: 1)). >> >> cell extent: 50@50. >> >> >> > >> > But this is not what I want! As I mentioned in a mail that was sent but >> never arrived. >> > I want a square and this is why I did >> > >> > BlCell>>initialize >> > super initialize. >> > self >> > shape: >> > (BlShape new >> > fillPaint: (BlColorPaint new color: (Color yellow)); >> > path: BlRectanglePath new); >> > extent: self extent >> > >> > >> > then I want to draw something extra this is why I overrode >> drawOnAthensCanvas: aCanvas >> > >> > Now I stop but I find bloc too complex. >> > >> > Sorry but I cannot lose time like that and just get frustrated at the >> end. >> > I will use the athens canvas directly and stay in morph for now. >> > >> > >> > I think there's a bit of misconception. >> > In Athens, shape representing any area you wanna fill with paint. >> Period. >> > It can be of any complexity, self-intersecting yadda yadda.. the main >> point is that it defines a region(s), that going to be filled with chosen >> paint during draw operation. >> > From perspective of morphs, as UI elements, most of them require some >> shape(s) to represent themselves on the screen. But there are morphs, that >> while still taking part in UI, don't need any shapes since they never drawn >> on the screen. >> > Another point is that nowhere said that morph can be represented by a >> one and only one shape period. Because as in your case, you want to, say, >> draw rectangle with paint A, and circle with paint B, then you basically >> need two different shapes (overlapping or not - not really matters) to >> represent morph on the screen. >> > >> > So, the first point in misconception comes from 'self shape:'.. >> > It is wrong from that perspective, because it is all fine, when morph >> using only single shape to represent itself.. but when you need multiple >> shapes, you are in trouble. It at least misleading, because provoking you >> to think that there can be only one. >> > >> > Then you need to invent a 'composite shape' that basically a collection >> of shapes for a single morph, that will represent it on the screen. >> > >> > A tangent to that, is that since most of morphs has mostly static >> geometry/topology and changing it very rarely and much less often comparing >> to drawing same shape(s) over and over again, it is right thing to define >> and initialize shape(s) and reuse them later in #draw method. Since you >> don't change shape(s), you don't have to generate new object(s). >> > From that perspective, this is nice, resource saving, approach. >> > But let us not forget, that this is just a 'statistical observation' >> and hence good to be a default setup. But it should not dictate you the >> rule(s). >> > You should still be able to define shape(s) on the fly or change it on >> the fly, dynamically. >> > >> > Another problematic is that you may want to use different shapes for >> > a) painting morph on screen >> > b) defining geometry of the morph for UI interactions. >> > As an example, let say, you want a rectangle with circle in centre on >> the screen, but also want morph to react on mouse over/clicks only if mouse >> cursor is inside a circle, but not when it's over an area covered by >> rectangle. >> > >> > What it means, that from UI perspective, you want from morph to define >> its shape, lets call it 'UI interaction shape'.. and from that perspective >> 'self shape:' is a good choice. But as example says, it has nothing to do >> with 'drawing shape(s)', which may or may not coincide with shape you using >> for UI interaction(s). >> > >> > Because it defines an area, where UI stuff could happen. And indeed, >> you really need one, and only one. You don't need multiple shapes there, >> since it serves to answer a simple question: 'are my mouse in interesting >> region or not'?. >> > Like in your case, when you having box with circle inside , which is >> two shapes, but only one shape that can define an interesting region, it >> could be: >> > - intersection of >> > - union >> > - subtraction >> > >> > And that could be completely different from shape(s) you may need to >> draw it on the screen. >> > >> > Stef >> > >> >> On Apr 2, 2016 4:57 PM, "stepharo" <stepharo(a)free.fr> wrote: >> >> Hi >> >> >> >> I want a square morph with a circle or a line at 45 degree inside >> >> Now I do not get it. >> >> >> >> I thought that I needed to specialize drawOnAthensCanvas: so I did >> >> >> >> BlCell >> drawOnAthensCanvas: aCanvas >> >> >> >> super drawOnAthensCanvas: aCanvas. >> >> aCanvas >> >> drawShape: (BlShape new >> >> strokePaint: >> >> (BlStrokePaint new >> >> paint: (BlColorPaint new >> color: (Color blue)); >> >> width: 15); >> >> path: BlCirclePath new). >> >> >> >> Now I do not know how I can specify a shape size >> >> >> >> So I will use another API than drawShape: >> >> >> >> Stef >> >> >> > >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Reasonable is what we are accustomed with." >> >> >> > > > -- > Best regards, > Igor Stasenko. >

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

On 3 April 2016 at 10:18, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > Thanks for this nice description :). > > Indeed, the Shape in Bloc is primarily a clipping shape that knows how to > draw the path around and to fill itself. Of course, it also handles the > interaction. > > When you want to have a composition, you are encouraged to create multiple > elements (morphs). This is a way to handle both more complicated > interaction and more complicated drawing. Of course, you can still override > the drawing method and draw whatever you want on it, but we would rather > have a simple composition. > > The disadvantage of this design is that indeed, is that it is not > sophisticated. The advantage of this design is that it is not sophisticated > :) and you get only one tree of compositions for the elements without > another level of composition at the shape level. The main reason we went > this route is because we want Bloc to pose as little constraints for the > things built on top as possible without losing power. > > Does this make sense for you? > It makes sense, sure thing. But it does not solves the problem. As i explained before, a single shape cannot serve as both clipping, UI handling and drawing all together. Because it is three separate roles, which is good if they coincide, but causing a lot of problems, when they are not. It is not matters how you compose or decompose shapes.. there is simply no composition which can turn rectangle into, lets say circle. it simply impossible to construct required clipping shape, or UI shape from set of drawing shapes, in case when they are completely different from each other. For instance if i want morph with rectangular appearance (rectangle shape) to respond on clicks only within circular subregion inside that rectangle, i will be forced to create a submorph and then rewire event handling back to its parent. And that happens every time i need a different shape for mouse clicks than shape for drawing. Now add clipping here... and you will get a nightmare of bells and whistles, composing and whatsnot. As for 'sophisticated'.. let see: so, in my proposition, i do: - draw rectangle and circle inside - define that circle as UI shape - define that rectangle as clipping shape done. In your design, i have to: - make a morph with rectangular shape - create submorph with circular shape - wire clicking of a submorph to propagate event to its parent or think about some kind of composition.. composing what with what? does it union of circle and rectangle? or intersection? depending the way how you composing those two shapes you receive one or another outcome.. and that event wiring is extra work.. So, it may look that what i proposing is more sophisticated.. But i just wanna see a separate roles taking own places, nothing else. I do not inventing new concepts, that wasn't there before: - you need clipping, - you need drawing - you need UI handling You see, it is not a framework, that forcing you to be 'sophisticated' .. it is domain itself. It draws a clear border between things that are optional and things that are absolutely necessary, since they are separate concepts and roles. You simply cannot represent an infinite dimension of drawing compositions by a composition of UI elements. Only the simplest cases.. It is big mistake to imply that anything that you drawing on screen must be a full-blown UI element (which is morph is) or their composition. It makes you quite limited in terms of what you can draw and what not. Morph is UI building brick.. but it is not graphical building brick.. making such parallel gives more troubles than it solves. To me concept where morph==shape==clipping shape==ui shape is just: - you can have bike of any color, as long as it's black. Can you enlighten me, what composition of black bikes can result in a green one? > > Cheers, > Doru > > > > On Apr 3, 2016, at 6:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > Oh, yeah.. i missed one more kind of shape, you may want to introduce: > > - clipping shape. > > > > For optimizing drawing operations, you may want to define a region, > which guarantees, that anything you paint, nothing outside defined region > will affect the screen. Because else, you will allow morph to render > anywhere and therefore, it is really hard for UI subsystem to account > damage on the screen. > > But once you define such shape, then you can clearly tell, which portion > of the screen may or may not be damaged and therefore act accordingly. > > > > So, overall when we talking about shapes, we need to talk about three > different kinds of them: > > > > - UI interaction shape > > - clipping shape > > - shape(s) used to draw > > > > those three may or may not coincide into single one, depending on > complexity and what you wanna do.. > > But they can be completely different from each other and in order to > avoid confusion and frustration, i would really introduce them in such > manner, that users have clear vision on what happens with their morphs and > how to achieve what they want. > > > > Clearly, a single #shape: is not enough, if you want a non-conflicting > representation of these concepts in UI. > > > > > > On 3 April 2016 at 07:15, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > > On 2 April 2016 at 20:59, stepharo <stepharo(a)free.fr> wrote: > > > > > > Le 2/4/16 17:31, Aliaksei Syrel a Ã©crit : > >> You don't want to draw a shape, you configure it. Shape can not be > drawn, it is not an AthensPath. > >> > >> cell shape: (BlShape new > >> path: BlCirclePath new; > >> strokePaint: (BlStrokePaint new > >> paint: Color blue; > >> width: 1)). > >> cell extent: 50@50. > >> > > > > But this is not what I want! As I mentioned in a mail that was sent but > never arrived. > > I want a square and this is why I did > > > > BlCell>>initialize > > super initialize. > > self > > shape: > > (BlShape new > > fillPaint: (BlColorPaint new color: (Color yellow)); > > path: BlRectanglePath new); > > extent: self extent > > > > > > then I want to draw something extra this is why I overrode > drawOnAthensCanvas: aCanvas > > > > Now I stop but I find bloc too complex. > > > > Sorry but I cannot lose time like that and just get frustrated at the > end. > > I will use the athens canvas directly and stay in morph for now. > > > > > > I think there's a bit of misconception. > > In Athens, shape representing any area you wanna fill with paint. Period. > > It can be of any complexity, self-intersecting yadda yadda.. the main > point is that it defines a region(s), that going to be filled with chosen > paint during draw operation. > > From perspective of morphs, as UI elements, most of them require some > shape(s) to represent themselves on the screen. But there are morphs, that > while still taking part in UI, don't need any shapes since they never drawn > on the screen. > > Another point is that nowhere said that morph can be represented by a > one and only one shape period. Because as in your case, you want to, say, > draw rectangle with paint A, and circle with paint B, then you basically > need two different shapes (overlapping or not - not really matters) to > represent morph on the screen. > > > > So, the first point in misconception comes from 'self shape:'.. > > It is wrong from that perspective, because it is all fine, when morph > using only single shape to represent itself.. but when you need multiple > shapes, you are in trouble. It at least misleading, because provoking you > to think that there can be only one. > > > > Then you need to invent a 'composite shape' that basically a collection > of shapes for a single morph, that will represent it on the screen. > > > > A tangent to that, is that since most of morphs has mostly static > geometry/topology and changing it very rarely and much less often comparing > to drawing same shape(s) over and over again, it is right thing to define > and initialize shape(s) and reuse them later in #draw method. Since you > don't change shape(s), you don't have to generate new object(s). > > From that perspective, this is nice, resource saving, approach. > > But let us not forget, that this is just a 'statistical observation' and > hence good to be a default setup. But it should not dictate you the rule(s). > > You should still be able to define shape(s) on the fly or change it on > the fly, dynamically. > > > > Another problematic is that you may want to use different shapes for > > a) painting morph on screen > > b) defining geometry of the morph for UI interactions. > > As an example, let say, you want a rectangle with circle in centre on > the screen, but also want morph to react on mouse over/clicks only if mouse > cursor is inside a circle, but not when it's over an area covered by > rectangle. > > > > What it means, that from UI perspective, you want from morph to define > its shape, lets call it 'UI interaction shape'.. and from that perspective > 'self shape:' is a good choice. But as example says, it has nothing to do > with 'drawing shape(s)', which may or may not coincide with shape you using > for UI interaction(s). > > > > Because it defines an area, where UI stuff could happen. And indeed, you > really need one, and only one. You don't need multiple shapes there, since > it serves to answer a simple question: 'are my mouse in interesting region > or not'?. > > Like in your case, when you having box with circle inside , which is two > shapes, but only one shape that can define an interesting region, it could > be: > > - intersection of > > - union > > - subtraction > > > > And that could be completely different from shape(s) you may need to > draw it on the screen. > > > > Stef > > > >> On Apr 2, 2016 4:57 PM, "stepharo" <stepharo(a)free.fr> wrote: > >> Hi > >> > >> I want a square morph with a circle or a line at 45 degree inside > >> Now I do not get it. > >> > >> I thought that I needed to specialize drawOnAthensCanvas: so I did > >> > >> BlCell >> drawOnAthensCanvas: aCanvas > >> > >> super drawOnAthensCanvas: aCanvas. > >> aCanvas > >> drawShape: (BlShape new > >> strokePaint: > >> (BlStrokePaint new > >> paint: (BlColorPaint new color: > (Color blue)); > >> width: 15); > >> path: BlCirclePath new). > >> > >> Now I do not know how I can specify a shape size > >> > >> So I will use another API than drawShape: > >> > >> Stef > >> > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > > -- Best regards, Igor Stasenko.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Tudor Girba

Hi Igor, Thanks for this nice description :). Indeed, the Shape in Bloc is primarily a clipping shape that knows how to draw the path around and to fill itself. Of course, it also handles the interaction. When you want to have a composition, you are encouraged to create multiple elements (morphs). This is a way to handle both more complicated interaction and more complicated drawing. Of course, you can still override the drawing method and draw whatever you want on it, but we would rather have a simple composition. The disadvantage of this design is that indeed, is that it is not sophisticated. The advantage of this design is that it is not sophisticated :) and you get only one tree of compositions for the elements without another level of composition at the shape level. The main reason we went this route is because we want Bloc to pose as little constraints for the things built on top as possible without losing power. Does this make sense for you? Cheers, Doru > On Apr 3, 2016, at 6:38 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Oh, yeah.. i missed one more kind of shape, you may want to introduce: > - clipping shape. > > For optimizing drawing operations, you may want to define a region, which guarantees, that anything you paint, nothing outside defined region will affect the screen. Because else, you will allow morph to render anywhere and therefore, it is really hard for UI subsystem to account damage on the screen. > But once you define such shape, then you can clearly tell, which portion of the screen may or may not be damaged and therefore act accordingly. > > So, overall when we talking about shapes, we need to talk about three different kinds of them: > > - UI interaction shape > - clipping shape > - shape(s) used to draw > > those three may or may not coincide into single one, depending on complexity and what you wanna do.. > But they can be completely different from each other and in order to avoid confusion and frustration, i would really introduce them in such manner, that users have clear vision on what happens with their morphs and how to achieve what they want. > > Clearly, a single #shape: is not enough, if you want a non-conflicting representation of these concepts in UI. > > > On 3 April 2016 at 07:15, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 2 April 2016 at 20:59, stepharo <stepharo(a)free.fr> wrote: > > > Le 2/4/16 17:31, Aliaksei Syrel a Ã©crit : >> You don't want to draw a shape, you configure it. Shape can not be drawn, it is not an AthensPath. >> >> cell shape: (BlShape new >> path: BlCirclePath new; >> strokePaint: (BlStrokePaint new >> paint: Color blue; >> width: 1)). >> cell extent: 50@50. >> > > But this is not what I want! As I mentioned in a mail that was sent but never arrived. > I want a square and this is why I did > > BlCell>>initialize > super initialize. > self > shape: > (BlShape new > fillPaint: (BlColorPaint new color: (Color yellow)); > path: BlRectanglePath new); > extent: self extent > > > then I want to draw something extra this is why I overrode drawOnAthensCanvas: aCanvas > > Now I stop but I find bloc too complex. > > Sorry but I cannot lose time like that and just get frustrated at the end. > I will use the athens canvas directly and stay in morph for now. > > > I think there's a bit of misconception. > In Athens, shape representing any area you wanna fill with paint. Period. > It can be of any complexity, self-intersecting yadda yadda.. the main point is that it defines a region(s), that going to be filled with chosen paint during draw operation. > From perspective of morphs, as UI elements, most of them require some shape(s) to represent themselves on the screen. But there are morphs, that while still taking part in UI, don't need any shapes since they never drawn on the screen. > Another point is that nowhere said that morph can be represented by a one and only one shape period. Because as in your case, you want to, say, draw rectangle with paint A, and circle with paint B, then you basically need two different shapes (overlapping or not - not really matters) to represent morph on the screen. > > So, the first point in misconception comes from 'self shape:'.. > It is wrong from that perspective, because it is all fine, when morph using only single shape to represent itself.. but when you need multiple shapes, you are in trouble. It at least misleading, because provoking you to think that there can be only one. > > Then you need to invent a 'composite shape' that basically a collection of shapes for a single morph, that will represent it on the screen. > > A tangent to that, is that since most of morphs has mostly static geometry/topology and changing it very rarely and much less often comparing to drawing same shape(s) over and over again, it is right thing to define and initialize shape(s) and reuse them later in #draw method. Since you don't change shape(s), you don't have to generate new object(s). > From that perspective, this is nice, resource saving, approach. > But let us not forget, that this is just a 'statistical observation' and hence good to be a default setup. But it should not dictate you the rule(s). > You should still be able to define shape(s) on the fly or change it on the fly, dynamically. > > Another problematic is that you may want to use different shapes for > a) painting morph on screen > b) defining geometry of the morph for UI interactions. > As an example, let say, you want a rectangle with circle in centre on the screen, but also want morph to react on mouse over/clicks only if mouse cursor is inside a circle, but not when it's over an area covered by rectangle. > > What it means, that from UI perspective, you want from morph to define its shape, lets call it 'UI interaction shape'.. and from that perspective 'self shape:' is a good choice. But as example says, it has nothing to do with 'drawing shape(s)', which may or may not coincide with shape you using for UI interaction(s). > > Because it defines an area, where UI stuff could happen. And indeed, you really need one, and only one. You don't need multiple shapes there, since it serves to answer a simple question: 'are my mouse in interesting region or not'?. > Like in your case, when you having box with circle inside , which is two shapes, but only one shape that can define an interesting region, it could be: > - intersection of > - union > - subtraction > > And that could be completely different from shape(s) you may need to draw it on the screen. > > Stef > >> On Apr 2, 2016 4:57 PM, "stepharo" <stepharo(a)free.fr> wrote: >> Hi >> >> I want a square morph with a circle or a line at 45 degree inside >> Now I do not get it. >> >> I thought that I needed to specialize drawOnAthensCanvas: so I did >> >> BlCell >> drawOnAthensCanvas: aCanvas >> >> super drawOnAthensCanvas: aCanvas. >> aCanvas >> drawShape: (BlShape new >> strokePaint: >> (BlStrokePaint new >> paint: (BlColorPaint new color: (Color blue)); >> width: 15); >> path: BlCirclePath new). >> >> Now I do not know how I can specify a shape size >> >> So I will use another API than drawShape: >> >> Stef >> > > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

Oh, yeah.. i missed one more kind of shape, you may want to introduce: - clipping shape. For optimizing drawing operations, you may want to define a region, which guarantees, that anything you paint, nothing outside defined region will affect the screen. Because else, you will allow morph to render anywhere and therefore, it is really hard for UI subsystem to account damage on the screen. But once you define such shape, then you can clearly tell, which portion of the screen may or may not be damaged and therefore act accordingly. So, overall when we talking about shapes, we need to talk about three different kinds of them: - UI interaction shape - clipping shape - shape(s) used to draw those three may or may not coincide into single one, depending on complexity and what you wanna do.. But they can be completely different from each other and in order to avoid confusion and frustration, i would really introduce them in such manner, that users have clear vision on what happens with their morphs and how to achieve what they want. Clearly, a single #shape: is not enough, if you want a non-conflicting representation of these concepts in UI. On 3 April 2016 at 07:15, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 2 April 2016 at 20:59, stepharo <stepharo(a)free.fr> wrote: > >> >> >> Le 2/4/16 17:31, Aliaksei Syrel a Ã©crit : >> >> You don't want to draw a shape, you configure it. Shape can not be drawn, >> it is not an AthensPath. >> >> cell shape: (BlShape new >> path: BlCirclePath new; >> strokePaint: (BlStrokePaint new >> paint: Color blue; >> width: 1)). >> cell extent: 50@50. >> >> >> But this is not what I want! As I mentioned in a mail that was sent but >> never arrived. >> I want a square and this is why I did >> >> BlCell>>initialize >> super initialize. >> self >> shape: >> (BlShape new >> fillPaint: (BlColorPaint new color: (Color yellow)); >> path: BlRectanglePath new); >> extent: self extent >> >> >> then I want to draw something extra this is why I overrode >> drawOnAthensCanvas: aCanvas >> >> Now I stop but I find bloc too complex. >> >> Sorry but I cannot lose time like that and just get frustrated at the >> end. >> I will use the athens canvas directly and stay in morph for now. >> >> > I think there's a bit of misconception. > In Athens, shape representing any area you wanna fill with paint. Period. > It can be of any complexity, self-intersecting yadda yadda.. the main > point is that it defines a region(s), that going to be filled with chosen > paint during draw operation. > From perspective of morphs, as UI elements, most of them require some > shape(s) to represent themselves on the screen. But there are morphs, that > while still taking part in UI, don't need any shapes since they never drawn > on the screen. > Another point is that nowhere said that morph can be represented by a one > and only one shape period. Because as in your case, you want to, say, draw > rectangle with paint A, and circle with paint B, then you basically need > two different shapes (overlapping or not - not really matters) to represent > morph on the screen. > > So, the first point in misconception comes from 'self shape:'.. > It is wrong from that perspective, because it is all fine, when morph > using only single shape to represent itself.. but when you need multiple > shapes, you are in trouble. It at least misleading, because provoking you > to think that there can be only one. > > Then you need to invent a 'composite shape' that basically a collection of > shapes for a single morph, that will represent it on the screen. > > A tangent to that, is that since most of morphs has mostly static > geometry/topology and changing it very rarely and much less often comparing > to drawing same shape(s) over and over again, it is right thing to define > and initialize shape(s) and reuse them later in #draw method. Since you > don't change shape(s), you don't have to generate new object(s). > From that perspective, this is nice, resource saving, approach. > But let us not forget, that this is just a 'statistical observation' and > hence good to be a default setup. But it should not dictate you the rule(s). > You should still be able to define shape(s) on the fly or change it on the > fly, dynamically. > > Another problematic is that you may want to use different shapes for > a) painting morph on screen > b) defining geometry of the morph for UI interactions. > As an example, let say, you want a rectangle with circle in centre on the > screen, but also want morph to react on mouse over/clicks only if mouse > cursor is inside a circle, but not when it's over an area covered by > rectangle. > > What it means, that from UI perspective, you want from morph to define its > shape, lets call it 'UI interaction shape'.. and from that perspective > 'self shape:' is a good choice. But as example says, it has nothing to do > with 'drawing shape(s)', which may or may not coincide with shape you using > for UI interaction(s). > > Because it defines an area, where UI stuff could happen. And indeed, you > really need one, and only one. You don't need multiple shapes there, since > it serves to answer a simple question: 'are my mouse in interesting region > or not'?. > Like in your case, when you having box with circle inside , which is two > shapes, but only one shape that can define an interesting region, it could > be: > - intersection of > - union > - subtraction > > And that could be completely different from shape(s) you may need to draw > it on the screen. > > Stef >> >> On Apr 2, 2016 4:57 PM, "stepharo" < <stepharo(a)free.fr>stepharo(a)free.fr> >> wrote: >> >>> Hi >>> >>> I want a square morph with a circle or a line at 45 degree inside >>> Now I do not get it. >>> >>> I thought that I needed to specialize drawOnAthensCanvas: so I did >>> >>> BlCell >> drawOnAthensCanvas: aCanvas >>> >>> super drawOnAthensCanvas: aCanvas. >>> aCanvas >>> drawShape: (BlShape new >>> strokePaint: >>> (BlStrokePaint new >>> paint: (BlColorPaint new color: >>> (Color blue)); >>> width: 15); >>> path: BlCirclePath new). >>> >>> Now I do not know how I can specify a shape size >>> >>> So I will use another API than drawShape: >>> >>> Stef >>> >>> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

On 2 April 2016 at 20:59, stepharo <stepharo(a)free.fr> wrote: > > > Le 2/4/16 17:31, Aliaksei Syrel a Ã©crit : > > You don't want to draw a shape, you configure it. Shape can not be drawn, > it is not an AthensPath. > > cell shape: (BlShape new > path: BlCirclePath new; > strokePaint: (BlStrokePaint new > paint: Color blue; > width: 1)). > cell extent: 50@50. > > > But this is not what I want! As I mentioned in a mail that was sent but > never arrived. > I want a square and this is why I did > > BlCell>>initialize > super initialize. > self > shape: > (BlShape new > fillPaint: (BlColorPaint new color: (Color yellow)); > path: BlRectanglePath new); > extent: self extent > > > then I want to draw something extra this is why I overrode > drawOnAthensCanvas: aCanvas > > Now I stop but I find bloc too complex. > > Sorry but I cannot lose time like that and just get frustrated at the end. > I will use the athens canvas directly and stay in morph for now. > > I think there's a bit of misconception. In Athens, shape representing any area you wanna fill with paint. Period. It can be of any complexity, self-intersecting yadda yadda.. the main point is that it defines a region(s), that going to be filled with chosen paint during draw operation. >From perspective of morphs, as UI elements, most of them require some shape(s) to represent themselves on the screen. But there are morphs, that while still taking part in UI, don't need any shapes since they never drawn on the screen. Another point is that nowhere said that morph can be represented by a one and only one shape period. Because as in your case, you want to, say, draw rectangle with paint A, and circle with paint B, then you basically need two different shapes (overlapping or not - not really matters) to represent morph on the screen. So, the first point in misconception comes from 'self shape:'.. It is wrong from that perspective, because it is all fine, when morph using only single shape to represent itself.. but when you need multiple shapes, you are in trouble. It at least misleading, because provoking you to think that there can be only one. Then you need to invent a 'composite shape' that basically a collection of shapes for a single morph, that will represent it on the screen. A tangent to that, is that since most of morphs has mostly static geometry/topology and changing it very rarely and much less often comparing to drawing same shape(s) over and over again, it is right thing to define and initialize shape(s) and reuse them later in #draw method. Since you don't change shape(s), you don't have to generate new object(s). >From that perspective, this is nice, resource saving, approach. But let us not forget, that this is just a 'statistical observation' and hence good to be a default setup. But it should not dictate you the rule(s). You should still be able to define shape(s) on the fly or change it on the fly, dynamically. Another problematic is that you may want to use different shapes for a) painting morph on screen b) defining geometry of the morph for UI interactions. As an example, let say, you want a rectangle with circle in centre on the screen, but also want morph to react on mouse over/clicks only if mouse cursor is inside a circle, but not when it's over an area covered by rectangle. What it means, that from UI perspective, you want from morph to define its shape, lets call it 'UI interaction shape'.. and from that perspective 'self shape:' is a good choice. But as example says, it has nothing to do with 'drawing shape(s)', which may or may not coincide with shape you using for UI interaction(s). Because it defines an area, where UI stuff could happen. And indeed, you really need one, and only one. You don't need multiple shapes there, since it serves to answer a simple question: 'are my mouse in interesting region or not'?. Like in your case, when you having box with circle inside , which is two shapes, but only one shape that can define an interesting region, it could be: - intersection of - union - subtraction And that could be completely different from shape(s) you may need to draw it on the screen. Stef > > On Apr 2, 2016 4:57 PM, "stepharo" < <stepharo(a)free.fr>stepharo(a)free.fr> > wrote: > >> Hi >> >> I want a square morph with a circle or a line at 45 degree inside >> Now I do not get it. >> >> I thought that I needed to specialize drawOnAthensCanvas: so I did >> >> BlCell >> drawOnAthensCanvas: aCanvas >> >> super drawOnAthensCanvas: aCanvas. >> aCanvas >> drawShape: (BlShape new >> strokePaint: >> (BlStrokePaint new >> paint: (BlColorPaint new color: >> (Color blue)); >> width: 15); >> path: BlCirclePath new). >> >> Now I do not know how I can specify a shape size >> >> So I will use another API than drawShape: >> >> Stef >> >> > -- Best regards, Igor Stasenko.

April 3, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Ben Coman

All forms of learning involve some degree criticism, and sometimes we learn the most from the hardest task masters. We all want a positive community, but we need to not fall into the trap of... "hacker forums where, out of some misguided sense of hyper-courtesy, participants are banned from posting any fault-finding with another's posts, and told âDon't say anything if you're unwilling to help the user.â The resulting departure of clueful participants to elsewhere causes them to descend into meaningless babble and become useless as technical forums. Exaggeratedly âfriendlyâ (in that fashion) or useful: Pick one. " [http://www.catb.org/esr/faqs/smart-questions.html] Its a balance to weave, but lets not be too quick on the trigger to impede someone's natural flow of thoughts. If too much burden is imposed to craft "cheerful" criticism, we might lose its contribution and the chance to learn. I learnt something from Igor's post. cheers -ben On Sat, Apr 2, 2016 at 6:07 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > You are more than welcome to come back. > > Too much acidity is good neither for you nor for the people around you :). Letâs be kind with one another and assume that we all care and we want to make this world a better place, but that at the same time we are still only humans. > > Cheers, > Doru > > > >> On Apr 1, 2016, at 10:51 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> On 1 April 2016 at 09:53, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> Nice to hear from you Igor. I am glad to see you around here. >> >> Hi, Doru. Yeah, i am considering whether i want to return to things i left, or not. So, expect more of my acid sarcasm in future. Maybe :) >> >> I do not see how your quote applies to the current case given that the original authors did not leave anywhere, but perhaps it was a joke, and I did not get it. >> >> We all will leave sooner or later. The only what matters is what we left behind :) >> >> Cheers, >> Doru >> >> >> > On Apr 1, 2016, at 5:54 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > >> > A perfect example of careless programming. >> > "I'll do it my way, and if it causing any problems, i don't care and i will just ignore them. And it's not my problem anyways, i went to something else already, since this part is works and DONE" >> > :) >> > >> > On 30 March 2016 at 14:33, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> > Please don't do this: >> > >> > updateHeight >> > "no need to care about height, when it's logic is not customized" >> > self layout isHeightCustom ifFalse: [ ^ self ]. >> > [ self bounds: (self brickBounds withHeight: self customHeight) ] >> > on: Exception >> > do: [ "just skip and do nothing" ] >> > >> > This makes debugging GLM/Brick ui/layout code with "self haltOnce" impossible. >> > see >> > GLMBrickGeometryTrait>>#updateHeight >> > GLMBrickGeometryTrait>>#updateWidth >> > >> > And if you log out the raised exception, you see some calls to >> > not initialized fonts and a ZeroDevide and some more errors. >> > The above catch, catches and hides wrong / to late initialized objects. >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "No matter how many recipes we know, we still value a chef." >> >> >> >> >> >> >> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > -- > www.tudorgirba.com > www.feenk.com > > "It's not how it is, it is how we see it." > >

April 3, 2016

Re: [Pharo-dev] Catching Exceptions without any notice

by Igor Stasenko

On 2 April 2016 at 17:31, stepharo <stepharo(a)free.fr> wrote: > > I did not expected such a warm welcome and being in vain for more than a >> year.. >> Thank you all guys, you are great! >> >> Yes, as i said i feel like i want to get some involvement.. So expect >> more acid in future, because that is my energy taking such unordinary form >> sometimes :) >> > > I'm really happy for you. > If you can help with the SDL 20 integration. I'm not sure that everything > you did in last year may was integrated. In fact we did not have the time > because of Spur and uFFI. In Pharo 60 we need to remove all the old event > chain and only use OSWindows. > > > Ronie will arrive a5 of April to Lille and he wants to work on Woden but > also it would be good to have his FFI (with special bytecode) integrated > into the JIT > so I imagine that clement, eliot, esteban and ronie should talk. > > I see. Thanks for heads up. > > Stef > > > > -- Best regards, Igor Stasenko.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Tudor Girba

Hi, > On Apr 3, 2016, at 12:46 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > I'm pretty sure we don't understand a meaning of composition identically. This is how I understand it: > > https://en.m.wikipedia.org/wiki/Composition_(visual_arts) > > "In graphic design for press and desktop publishing composition is commonly referred to as page layout." > > Design for press is inspiration of modern ui design techniques, for example material design. > > Concentrate on "page layout". Then comes the following question: if composition is archived through layout of elements why Stef tries to manually draw shapes instead of composing two elements? > Howto: > 1) Create an element with rectangle shape. > 2) Create an element with circle shape. > 3) Add circle element to rectangle element. > 4) Change layout params of the circle element to match parent both vertically and horizontally > 5) if needed set padding/margin. > > There is even no need to care about drawing if it's complicated. That is exactly the point :). I think for such scenarios we should encourage people to use composition of elements. I think that Stef has a use case of the way the element should look like in the end, and he wants to get it done, and I think we should provide examples that guide him to what the best route should be. Anyway, this probably reveals the miscommunication. @Stef: did you want to necessarily play with the low level drawing, or do you just want to get to an element with a rectangle that has a circle inside? Cheers, Doru > On Apr 3, 2016 12:26 AM, "Tudor Girba" <tudor(a)tudorgirba.com> wrote: > Hi Alex, > > I think that Stef is looking for a composition example. Could you please provide an example that is more canonical and shows the composition of two elements instead of playing with both drawOnSpartaCanvas and the shape? > > Cheers, > Doru > > > > On Apr 2, 2016, at 8:17 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > > > How to make square element with filled circle inside: > > > > 1) Subclass BlElement -> BlCell > > 2) Override > > drawOnSpartaCanvas: aCanvas > > super drawOnSpartaCanvas: aCanvas. > > aCanvas > > setShape: self localBounds; > > setStrokePaint: Color blue; > > stroke > > > > 3) Override initialize to have circle shape: > > initialize > > super initialize. > > self shapeDo: [ :aShape | aShape > > path: BlCirclePath new; > > fillPaint: Color red ]. > > 4) Open cell in word > > > > Easy :) > > > > -- > www.tudorgirba.com > www.feenk.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of reality." > > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

April 2, 2016