On 3 April 2016 at 19:43, Thierry Goubier <thierry.goub...@gmail.com> wrote:
> Hi Alex, Igor and others, > > this discussion is interesting to follow. GUI frameworks are hard... > > Le 03/04/2016 16:58, Aliaksei Syrel a écrit : > >> And you lost me here.. That is complete nonsense.. from any >> perspective. >> Can i unsee this code, please? :) >> >> >> If I would say that we have defaultShape method and it can be overridden >> as: >> >> defaultShape >> ^ BlShape new >> fillPaint: (BlColorPaint new color: (Color yellow)); >> path: BlRectanglePath new >> >> would it make you happy? >> > > If you don't tell me there is a cost for creating a shape in athens, I'll > wonder if you're not asking me to optimise by caching a shape; and that is > over-engineering. Of course, creating shapes has own cost, as anything else. But, guess what, you having caching mechanism in Athens out of the box, if you don't happy with performance. > > >> .. to me it feels like: okay, what we need to do, to prevent >> overrides of our beloved default #drawOn: method. >> >> You are wrong concerning preventing to override drawOn :) >> > > I wonder if that "shape" thing is not something like the difference > between Roassal and Trachel: RT vs TR objects. And, yes, for me, the RT/TR > hierarchy is a reimplementation of objects over Athens, and the end result > is that it is easy to compose existing objects in Roassal and hard to > extend it. > Sad. Sarcasm tries to flow from my tongue. But i will keep my mouth shut. No comments :) > > Don't forget that there was a customer *requirement* concerning bloc: >> >> Can we change how morph looks on fly? Can we create a rectangle morph >> and change it's shape from rectangle to circle? Because it can nicely >> show while presenting that *Pharo is live system*. I'm pretty sure Stef >> said it once ago. >> > > If that is your requirement, then this is bad. > > It's a demo requirement with costly consequences. Does it apply in real > life in a system where recreating a complete Morph is so cheap (witness > FastTable!)? I'd say no. > > Do you see how bloc story can nicely be told: >> >> We have basic UI elements and each element has shape that can be >> easily changed live. Shape is defined by a path which can be filled >> or stroked using a paint. Complex elements can be created as >> composition of elements with basic shapes (rectangle, circle). >> >> >> Isn't it beautiful? :) >> > > It is, but it tells of complexity: UI behavior composition (not only > graphics). Extending elements may also require extending shapes and > understanding how they interact and compose. > That is road to nowhere. You already having morphs for composition. No need to introduce 'elements' to compose something inside composition of morphs.. If you cannot do something out of composition of morphs, what makes you think that you can do it introducing another layer of composition? Maybe you shall think that composition is a wrong tool in that case? > > Regards, > > Thierry > > -- Best regards, Igor Stasenko.
