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

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by Erik Stel

Hi Igor and others, (Without having seen any of the code, but from experience on other (Javascript) project, beziers might be useful. Maybe the mentioned approach for polygon approximation is already based on beziers. Forgive me for wasting your time in that case.) Beziers may be a good starting point for different kinds of tests/transformations/etc. Most shapes (should I say Paths here? ;-) can be specified as (cubic) beziers or approximated, allowing these tests/transforms on all shapes. See http://pomax.github.io/bezierinfo/ for the explanation and the Javascript-code. Nice read for anyone interested in some maths concerning beziers. Cheers, Erik -- View this message in context: http://forum.world.st/bloc-I-do-not-understand-why-some-behavior-is-not-in-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 5, 2016

Re: [Pharo-dev] TxText model

by Ben Coman

On Mon, Apr 4, 2016 at 9:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> >> >> 2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >>> >>> >>>> >>> Analogies don't work. Right :) I never used Pillar and have remote ideas >>> about what it does or requires. From that perspective you appeal to wrong >>> person. On your place i would be asking a guy who knows Pillar innards about >>> it. Please see... [1] http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf [2] https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… Most (all?) of docs at [3] are done using Pillar... [3] https://github.com/SquareBracketAssociates cheers -ben

April 5, 2016

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by Ben Coman

On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Some more bashing today.. (don't take it personal, i may be wrong) > > BlPath hierarchy.. and BlShape. > > Why you redefining what is shape and what is path? > Of course, you are free to do it in Bloc.. > But in terms of Athens, all of BlPath are actually - shapes.. > And BlShape is some kind of encapsulation of shape, paints and transform. > It is a dumb state holder without any extra logic. > > My rule of thumb: do not produce dumb state holders. They has to be smart, > else it makes no sense in creating separate entity and designating it as > something else than any other bunch of data thrown into single clump, > sitting there deaf, blind, dead and silent until someone else will grab it > somewhere > and start using it for own purpose. > > Sure, i could understand, why you potentially may want such object(s) > around, > but it is not shape anymore and i wouldn't call it like that. Because shape > are shape, and has nothing to do with paints and transform, > it don't knows and don't cares whether it will be filled or stroked or both, > and how many times, and if there will be single paint or thousand. > Such kind of properties is simply orthogonal to what shape existing for, > because it exists only to define geometry. > > I think all of that came from not understanding the roles of objects and how > they interact in Athens. Can you point us to documentation that describes Athen's architecture for these interactions? (sorry I haven't checked class comments, but I'm looking to start with something at higher level anyway) cheers -ben

April 5, 2016

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by Aliaksei Syrel

About hit detection. Idea was to be completely general. And this is the only approach I found (still bad because uses native calls instead of athens-like solution) that works with text. Text is also a shape and it's very cool to be able to detect events inside characters. Imagine morph in form of huge arbitrary string. Current solution does not render, it only sets fill paint and path, then uses cairo, no need to invent wheel. Imagine that paint is something fancy, Cairo takes Cairo about special cases. Cheers Alex On Apr 5, 2016 12:17 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: > > > On 5 April 2016 at 01:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 5 April 2016 at 00:51, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >> >> btw, Andrei , if you looking how you can test if point contains shape or >> not, take a look at AthensCurveFlattener. >> It converts curved path, that containing Bezier curves (or not) into >> simple polygonal shape that consists only from a simple lines. >> Then there AthensPolygonTester, that has the piece you missing: >> - a small algorithm that can test if given point inside or outside that >> polygon. >> >> Please note that it is simpler even-odd rule algorithm. It not works >> correctly for all possible cases. >> >> There's another algorithm- winding number algorithm, that is much better, >> but i had to switch to other stuff before were able to get my hands to it. >> It is more reliable, since it can work for self-intersecting shapes. >> >> https://en.wikipedia.org/wiki/Point_in_polygon >> >> So, what you need is to wire these things down to Bloc.Then whenever you >> need to test whether point within shape or not, you can convert any path >> into polygon and perform the test. And of course, you can cache the results >> of conversion in order to avoid expensive computations every time you need >> to perform such tests. Once path is converted, the test is relatively cheap >> and costs something like O(n), where n is number of line segments. >> >> Or maybe, to simplify things, you could extend the shape protocol and >> introduce #containsPoint: >> or as variant #containsPoint:ifNotAvailable: >> so that if shape implements such feature - it can answer true or false, >> and if not - evaluating a block. So, you don't have to implement all tests >> for all kinds of shapes that invented or not yet invented in universe. >> >> > Oh, forgot to add, you can look for example how i converting path in > AthensBezier3Scene class. > > >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. >

April 4, 2016

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by Aliaksei Syrel

> Seriously, brute force is synonym of dumb. If you cannot solve the problem by anything else than using brute force, then first thing you do, you leave an extensive comment "sorry guys, this piece stinks, but i was <...> unable to do any better". That is enough, Igor. Calling other developers or their decisions "dumb" is unacceptable! It is far way beyond a red line and only shows impoliteness. You are not trying to constructively criticize but just trolling us. Here are some basic rules if you want to continue discussion: 1) Before "pushing" other people to spend time on you, try to spend your own. Read previous posts at least in the same thread before writing an email. Link to bloc build was in the second email but you asked for it 2 or 3 messages later. 2) Don't use "pfff...", "yadda yadda", " pony" or whatever other jargon in any thread related to bloc. It distracts and shows your disregard to the reader. 3) Don't judge others that they don't know or understand something. There are no stupid people around here. 4) Write short but informative emails. We have a lot of other stuff to do. Everything that you wrote can be expressed using much less amount of characters. 5) First ask why decision was made and only then describe cons and pros. There is obsolete code in multiple places left because it maybe forgotten or we realized that it was a mistake but accidentally committed. That shadow problem was a mistake and big thanks to Glenn who explained and fixed it in bloc a lot of month ago by using ShadowFilter which is in another repo for a moment. 6) When criticizing try to find and mention also positive desicions. It is called politeness. Thanks Alex On 5 April 2016 at 01:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 5 April 2016 at 00:51, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > btw, Andrei , if you looking how you can test if point contains shape or > not, take a look at AthensCurveFlattener. > It converts curved path, that containing Bezier curves (or not) into > simple polygonal shape that consists only from a simple lines. > Then there AthensPolygonTester, that has the piece you missing: > - a small algorithm that can test if given point inside or outside that > polygon. > > Please note that it is simpler even-odd rule algorithm. It not works > correctly for all possible cases. > > There's another algorithm- winding number algorithm, that is much better, > but i had to switch to other stuff before were able to get my hands to it. > It is more reliable, since it can work for self-intersecting shapes. > > https://en.wikipedia.org/wiki/Point_in_polygon > > So, what you need is to wire these things down to Bloc.Then whenever you > need to test whether point within shape or not, you can convert any path > into polygon and perform the test. And of course, you can cache the results > of conversion in order to avoid expensive computations every time you need > to perform such tests. Once path is converted, the test is relatively cheap > and costs something like O(n), where n is number of line segments. > > Or maybe, to simplify things, you could extend the shape protocol and > introduce #containsPoint: > or as variant #containsPoint:ifNotAvailable: > so that if shape implements such feature - it can answer true or false, > and if not - evaluating a block. So, you don't have to implement all tests > for all kinds of shapes that invented or not yet invented in universe. > > Oh, forgot to add, you can look for example how i converting path in AthensBezier3Scene class. > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

April 4, 2016

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by Igor Stasenko

On 5 April 2016 at 00:50, Anonymous <anonymousknight(a)hmamail.com> wrote: > As far as I know bloc already has perfect hit detection. In BlPath. What a > dumb state holder! > > Aha, i see - containsX: x Y: y render the path to determine if it contains point or not. Thank you for pointing out! Now i have another reason for yet another rant! Seriously, brute force is synonym of dumb. If you cannot solve the problem by anything else than using brute force, then first thing you do, you leave an extensive comment "sorry guys, this piece stinks, but i was <...> unable to do any better". That at least won't aflame people when they will look at it :) > -- > View this message in context: > http://forum.world.st/bloc-I-do-not-understand-why-some-behavior-is-not-in-… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Best regards, Igor Stasenko.

April 4, 2016

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by Igor Stasenko

On 5 April 2016 at 01:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 5 April 2016 at 00:51, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > btw, Andrei , if you looking how you can test if point contains shape or > not, take a look at AthensCurveFlattener. > It converts curved path, that containing Bezier curves (or not) into > simple polygonal shape that consists only from a simple lines. > Then there AthensPolygonTester, that has the piece you missing: > - a small algorithm that can test if given point inside or outside that > polygon. > > Please note that it is simpler even-odd rule algorithm. It not works > correctly for all possible cases. > > There's another algorithm- winding number algorithm, that is much better, > but i had to switch to other stuff before were able to get my hands to it. > It is more reliable, since it can work for self-intersecting shapes. > > https://en.wikipedia.org/wiki/Point_in_polygon > > So, what you need is to wire these things down to Bloc.Then whenever you > need to test whether point within shape or not, you can convert any path > into polygon and perform the test. And of course, you can cache the results > of conversion in order to avoid expensive computations every time you need > to perform such tests. Once path is converted, the test is relatively cheap > and costs something like O(n), where n is number of line segments. > > Or maybe, to simplify things, you could extend the shape protocol and > introduce #containsPoint: > or as variant #containsPoint:ifNotAvailable: > so that if shape implements such feature - it can answer true or false, > and if not - evaluating a block. So, you don't have to implement all tests > for all kinds of shapes that invented or not yet invented in universe. > > Oh, forgot to add, you can look for example how i converting path in AthensBezier3Scene class. > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

April 4, 2016

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by Igor Stasenko

On 5 April 2016 at 00:51, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: btw, Andrei , if you looking how you can test if point contains shape or not, take a look at AthensCurveFlattener. It converts curved path, that containing Bezier curves (or not) into simple polygonal shape that consists only from a simple lines. Then there AthensPolygonTester, that has the piece you missing: - a small algorithm that can test if given point inside or outside that polygon. Please note that it is simpler even-odd rule algorithm. It not works correctly for all possible cases. There's another algorithm- winding number algorithm, that is much better, but i had to switch to other stuff before were able to get my hands to it. It is more reliable, since it can work for self-intersecting shapes. https://en.wikipedia.org/wiki/Point_in_polygon So, what you need is to wire these things down to Bloc.Then whenever you need to test whether point within shape or not, you can convert any path into polygon and perform the test. And of course, you can cache the results of conversion in order to avoid expensive computations every time you need to perform such tests. Once path is converted, the test is relatively cheap and costs something like O(n), where n is number of line segments. Or maybe, to simplify things, you could extend the shape protocol and introduce #containsPoint: or as variant #containsPoint:ifNotAvailable: so that if shape implements such feature - it can answer true or false, and if not - evaluating a block. So, you don't have to implement all tests for all kinds of shapes that invented or not yet invented in universe. -- Best regards, Igor Stasenko.

April 4, 2016

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by Andrei Chis

On Mon, Apr 4, 2016 at 11:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 4 April 2016 at 23:17, stepharo <stepharo(a)free.fr> wrote: > >> Doru >> >> I have the impression that >> clipping and interaction can be defined by a "shape" >> then the drawing can be either drawn in a canvas or delegate to something >> else (for example for the cursor if there is an hardware rendering). >> >> I like this discussion and the feedback of igor because he is kicking our >> asses much better than me in fact >> because he has real argument while I just got feelings :) >> >> It is easy to kick asses.. much easier than doing things. > And please, explain to guys, that i am not some kind of trolly crazy angry > idiot, who sits in the corner making giggles and throwing paperballs into > student(s), because its fun. > It is because i also made similar mistakes, or have to fix other's > mistakes at own time, and really don't want people repeating them over and > over again, like ShadowCanvas, now its ShadowPaint. > yes, shadow should not be a paint. We discussed and decided to change that a few month ago just forgot to remove it. Cheers, Andrei > > > >> Stef >> >> Le 4/4/16 19:10, Tudor Girba a Ã©crit : >> >> Hi, >>> >>> Indeed, this was not clear. The original idea of the shape was to be >>> primarily responsible for the clipping, but in the meantime the stroke and >>> fill filtered in the implementation. Alex, Andrei and I will now change the >>> âshapeâ to only be responsible for clipping and leave the drawing to the >>> element. We will also propose a solution for dealing with drawing and >>> interaction. >>> >>> Please stay tuned and thanks for this discussion. >>> >>> Cheers, >>> Doru >>> >>> >>> On Apr 4, 2016, at 9:00 AM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> I saw in bleedingEdge it is different and looks better. >>>> Now I was wondering why shape did not do the rendering and I thought >>>> that this is may be because a shape can be used for doing something else >>>> than rendering. For example clipping or as igor mentioned defining the >>>> shape of the interaction >>>> >>>> >>>> >>>> drawOnSpartaCanvas: aCanvas >>>> "Actually render receiver on aCanvas in local bounds. >>>> Override to customize. >>>> aCanvas is an instance of AthensCanvas >>>> aCanvas must not be nil" >>>> >>>> self assert: self shape path context isNotNil. >>>> >>>> aCanvas >>>> clipPreserveBy: self shape during: [ >>>> aCanvas paintGroup: [ >>>> aCanvas setPaint: self shape fillPaint. >>>> aCanvas fillPreserve. >>>> aCanvas paintMode source. >>>> aCanvas setStrokePaint: self shape strokePaint. >>>> aCanvas stroke ] ] >>>> >>>> >>>> >>>> unprotectedFullDrawOnSpartaCanvas: aCanvas >>>> "Draw the full structure on the given Canvas withing drawing bounds >>>> without caring about any errors and visibility. I am responsible for >>>> clipping and transforming canvas's path to local coordinates >>>> to allow simpler actual drawing in drawOnAthensCanvas: >>>> Additional checks should be implemented in fullDrawOnAthensCanvas: >>>> aCanvas is an instance of AthensCanvas. >>>> aCanvas must not be nil. >>>> @see BlElement>>#fullDrawOnAthensCanvas: >>>> @see BlElement>>#drawOnAthensCanvas:" >>>> self shape adaptTo: self. >>>> self shape path context: aCanvas. >>>> >>>> aCanvas >>>> transform: self transformation >>>> during: [ >>>> self clippingStrategy >>>> clip: self >>>> on: aCanvas >>>> during: [ self drawOnSpartaCanvas: aCanvas ] >>>> childrenDuring: [ self drawChildrenOnSpartaCanvas: >>>> aCanvas ] ] >>>> >>>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "To utilize feedback, you first have to acquire it." >>> >>> >>> >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

April 4, 2016

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by Anonymous

As far as I know bloc already has perfect hit detection. In BlPath. What a dumb state holder! -- View this message in context: http://forum.world.st/bloc-I-do-not-understand-why-some-behavior-is-not-in-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 4, 2016