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 Igor Stasenko

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. > 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 Igor Stasenko

On 4 April 2016 at 23:21, stepharo <stepharo(a)free.fr> wrote: > Hi igor > > I like your feedback. > Could you summarize it based on the latest alpha version and now that you > saw the code? > > My biggest source of concern, when i look at it is attempt to funnel features of Athens to obfuscate it down to the point that only simple, prescribed and rigid constructions will be possible. Athens is not perfect. As nothing is perfect. More than that: it proposing a quite limited subset of features comparing to other modern graphical engines. That's why i really surprised to see how people want to 'simplify' it even more, down to simplest possible constructs and throwing away the plethora of other possibilities. What was the point to make all those features, if you don't want to expose them to user? Or exposing them in a way, that most of them become hardly reachable. You cannot have a richer feature set than base engine provides, especially by shrinking that base. > In the bloc version you discussed with alain (in the house I was > renovating) an element had a view that were responsibe of the rendering > but it was not good. > > I don't remember. The only view as a concept i can think of, we were discussing was a so-called 'viewport'. Is like defining a physical area on screen which are controlled by GUI, while other areas can be occupied by something else (be it other GUI kind, or 3D application etc). But in usual desktop, desktop covers whole screen and there seems like no huge outcry 'we need special views', so i would put it into 'good to have but not absolutely necessary' box. > Stef > > Le 4/4/16 20:51, Igor Stasenko a Ã©crit : > > > 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. > > Shapes define geometry. > Paints define how that geometry will be filled/altered. > The shapes and paints are related in a way that paints are used to fill > shapes. But there's nothing tells that single shape can be filled only > once with prescribed paint, and only then stroked.. or vise versa. > The order and amount of operations, combinations and effects are up to the > user. And they have to stay like so, if you don't intend to shrink feature > set and hardwire, what users can do and what they cannot. > I really hoping that you had no such intent. > > > Be on your place, if you want to have a number of commonly used shapes, > just make a > factory class, so i can tell: > > CommonShapes rectangle: a@b to: c@d > > except, that Rectangle is a shape already.. and wrapping it with own class > just adds more complexity, creating one extra beloved dumb state holder > and nothing else. > > But i would imagine i could have: > > CommonShapes circle: 100@100 > or > CommonShapes roundedRectangle: 100@100 radius: 5 > > in any case, since there could be infinite number of 'possibly useful > objects' > when we talking about geometry.. your BlPath hierarchy will tend to grow > and grow over time, ad infinity. > Well, people love when there's order, like in that comic where guy painted > 'cat' label on his cat, 'car' label on his car.. and all around in same > way. > Can't blame for that.. So, maybe. Whatever.. > > But your examples demonstating insane amount of bloat.. > > For example: > > exampleLine > self new > layoutStrategy: BlLinearLayout horizontal; > layoutParamsDo: [ :lp | > lp horizontal wrapContent. > lp vertical wrapContent ]; > addChild:(self new > layoutParams: BlLinearLayoutParams new; > shape: > (BlShape new > fillPaint: (BlColorPaint new color: (Color blue alpha: 0.5)); > strokePaint: > (BlStrokePaint new > paint: (BlColorPaint new color: (Color green alpha: 1)); > lineStyle: BlStrokeLineStyle new; > width: 5); > path: (BlLinePath new)); > extent: 400 @ 200); > openInWorld > > > Guys, are you serious, you will find happy users, that is forced to > produce so much > code in order to draw a single, simple line on the screen? > You must be kidding. > > I see that it is indeed comes from the requirement that BlElement can > hot-swap its shape on the fly.. And so, you are forced to define all the > properties > and construct all the things in place. > But there should be some sanity limit, where you should stop asking user > for > so much details. > > But if you want to go to such extreme, then all your examples would look > like that: > > BlElement new > content: (MyFancyPony new); > openInWorld. > > Where MyFancyPony, is a content - an object that defines shape, and knows > how to render itself and so on. A smart object, that knows how to behave > and draw itself. Not just holding state. > And number of properties and/or behavior > is then up to the user. And he is free to use anything fancy or not to > deliver content on the screen. > > That would be much better. But then it will duplicate the features of > BlElement (or at least a significant subset of it) - being able to render > itself. > But still. > > P.S. Now i see BlElement.. why nobody said that it is replacement for > Morph? > I was thinking that in addition to BlMorph, you have BlElement :) > Sure, you don't need two compositions. As long as there one thing that > represent UI elements, that can form hierarchy its ok. > So, i retract my comments about Elements.. And apologize. > > -- > 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 Andrei Chis

Hi Stef, Currently there was a distinction between Shape and Path which turn out to be confusing. So Shape will go away and there will be just a Path (line, circle, rectangle, etc). We started to refactor this during the PharoDays. And yes, Rectangle will be polymorphic with Path. BlElement does support clipping and click detection by paths but right now they were implicit and you needed to subclass BlElement to override them independently. We'll change this so one can set them independently in BlElement. Yes, BlElement had a default path for drawing but that will go away. By default BlElement will have an empty drawOn... method. So to create a custom widget you can subclass BlElement, override drawOn... and use the canvas to draw anything you wish. There will be a subclass of BlElement that will add more drawing oriented logic but BlElement will be independent of that. Yes, the API of the canvas is not perfect but we're improving. Cheers, Andrei On Mon, Apr 4, 2016 at 6:00 PM, 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 > ] ] > >

April 4, 2016

Re: [Pharo-dev] TxText model

by Thierry Goubier

Le 04/04/2016 22:02, Damien Pollet a Ã©crit : > > On 4 April 2016 at 17:21, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > > Did you had a look at the Doc code (of Design Pattern fame)? It has > allways been freely available. > > > no, what is it? do you have a link? Found it: it's in the original InterViews tar file: http://www.ivtools.org/ivtools/faq.html#whataboutdoc And, as they say: it should built against the interviews library in ivtools. Someone with a stackoverflow account could complement the answers :) http://stackoverflow.com/questions/4829227/gang-of-four-lexi-editor-c-source Regards, Thierry

April 4, 2016

Re: [Pharo-dev] TxText model

by Thierry Goubier

Le 04/04/2016 22:02, Damien Pollet a Ã©crit : > > On 4 April 2016 at 17:21, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > > Did you had a look at the Doc code (of Design Pattern fame)? It has > allways been freely available. > > > no, what is it? do you have a link? It's an old WYSIWIG text editor written in C++, implementing the TeX typesetting, and source of a bunch of patterns of the Design Patterns book (flyweight for character glyphs). It was a part of the InterViews toolkit (J. Vlissides et al), and was maintained (and is still maintained) as ivtools (http://www.ivtools.org) Somewhere in there one could find a way to build Doc, but I can't find it anymore. Haven't built it in more than ten years... Thierry

April 4, 2016

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

by stepharo

Hi igor I like your feedback. Could you summarize it based on the latest alpha version and now that you saw the code? In the bloc version you discussed with alain (in the house I was renovating) an element had a view that were responsibe of the rendering but it was not good. Stef Le 4/4/16 20:51, Igor Stasenko a Ã©crit : > > 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. > > Shapes define geometry. > Paints define how that geometry will be filled/altered. > The shapes and paints are related in a way that paints are used to > fill shapes. But there's nothing tells that single shape can be > filled only once with prescribed paint, and only then stroked.. or > vise versa. > The order and amount of operations, combinations and effects are up to > the user. And they have to stay like so, if you don't intend to shrink > feature set and hardwire, what users can do and what they cannot. > I really hoping that you had no such intent. > > > Be on your place, if you want to have a number of commonly used > shapes, just make a > factory class, so i can tell: > > CommonShapes rectangle: a@b to: c@d > > except, that Rectangle is a shape already.. and wrapping it with own class > just adds more complexity, creating one extra beloved dumb state > holder and nothing else. > > But i would imagine i could have: > > CommonShapes circle: 100@100 > or > CommonShapes roundedRectangle: 100@100 radius: 5 > > in any case, since there could be infinite number of 'possibly useful > objects' > when we talking about geometry.. your BlPath hierarchy will tend to > grow and grow over time, ad infinity. > Well, people love when there's order, like in that comic where guy > painted 'cat' label on his cat, 'car' label on his car.. and all > around in same way. > Can't blame for that.. So, maybe. Whatever.. > > But your examples demonstating insane amount of bloat.. > > For example: > > exampleLine > self new > layoutStrategy: BlLinearLayout horizontal; > layoutParamsDo: [ :lp | > lp horizontal wrapContent. > lp vertical wrapContent ]; > addChild:(self new > layoutParams: BlLinearLayoutParams new; > shape: > (BlShape new > fillPaint: (BlColorPaint new color: (Color blue alpha: 0.5)); > strokePaint: > (BlStrokePaint new > paint: (BlColorPaint new color: (Color green alpha: 1)); > lineStyle: BlStrokeLineStyle new; > width: 5); > path: (BlLinePath new)); > extent: 400 @ 200); > openInWorld > > > Guys, are you serious, you will find happy users, that is forced to > produce so much > code in order to draw a single, simple line on the screen? > You must be kidding. > > I see that it is indeed comes from the requirement that BlElement can > hot-swap its shape on the fly.. And so, you are forced to define all > the properties > and construct all the things in place. > But there should be some sanity limit, where you should stop asking > user for > so much details. > > But if you want to go to such extreme, then all your examples would > look like that: > > BlElement new > content: (MyFancyPony new); > openInWorld. > > Where MyFancyPony, is a content - an object that defines shape, and > knows how to render itself and so on. A smart object, that knows how > to behave and draw itself. Not just holding state. > And number of properties and/or behavior > is then up to the user. And he is free to use anything fancy or not to > deliver content on the screen. > > That would be much better. But then it will duplicate the features of > BlElement (or at least a significant subset of it) - being able to > render itself. > But still. > > P.S. Now i see BlElement.. why nobody said that it is replacement for > Morph? > I was thinking that in addition to BlMorph, you have BlElement :) > Sure, you don't need two compositions. As long as there one thing that > represent UI elements, that can form hierarchy its ok. > So, i retract my comments about Elements.. And apologize. > > -- > 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 stepharo

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 :) 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." > > >

April 4, 2016

Re: [Pharo-dev] Pharo Days 2016 Photos and Video

by stepharo

>> On 04 Apr 2016, at 09:15, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Good morning everyone! >> >> I think that itâs a nice way to start the new week by viewing photos from Pharo Days 2016: https://goo.gl/photos/orgTn4C1bSeqf6fy5. >> Additionally if someone wants to get a quick impression of the conference, now there is a video for that: https://youtu.be/eHKtxgbuLSg. > Beautiful ! > > Thank you. +1 > >> Have a great week. >> Cheers! >> Uko > >

April 4, 2016

Re: [Pharo-dev] TxText model

by Damien Pollet

On 4 April 2016 at 17:21, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Did you had a look at the Doc code (of Design Pattern fame)? It has > allways been freely available. no, what is it? do you have a link? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

April 4, 2016

Re: [Pharo-dev] Pharo Days 2016 Photos and Video

by stepharo

Thanks Yuriy I wished I had more energy but I need holidays. Le 4/4/16 09:15, Yuriy Tymchuk a Ã©crit : > Good morning everyone! > > I think that itâs a nice way to start the new week by viewing photos > from Pharo Days 2016: https://goo.gl/photos/orgTn4C1bSeqf6fy5. > Additionally if someone wants to get a quick impression of the > conference, now there is a video for that: https://youtu.be/eHKtxgbuLSg. > > > Have a great week. > Cheers! > Uko

April 4, 2016