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

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

by Igor Stasenko

On 3 April 2016 at 19:48, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 03/04/2016 17:33, stepharo a Ã©crit : > >> 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. >>> >>> I see clearly point of Igor. And for me it feels very logical. >>> With such design you can lively change clipping area and >>> interaction area for any morph (element) on screen. >>> >>> >>> In short, i see only two cases where indeed, morph requires a nothing >>> of shapes to define: >>> - clipping region(s) >>> - ui interaction region(s) >>> >>> but for drawing? nooooo... really? who cares what you draw there? >>> draw anything, in any possible way you see fit.. compose, decompose, >>> recombine, blend and mix.. that's the whole purpose of drawing and be >>> artistic and be able to express yourself in any possible way you want :) >>> Why nailing and formalizing things that are tend to be hardly >>> formalizable and more than that, unnecessary. >>> That's my main concern about current design. >>> >> >> I agree. >> I do not see why people are forced to create a submorph just to change >> the rendering. >> If you want to change it dynamically you can for example pass a >> different shape. >> > > I don't see the problem with subclassing a morph. > > Me neither. But do you confusing subclassing and submorph compositing? > The reverse: I feel like current Morphs are huge monsters of > configurability and parameter blocks and properties and intricated code and > thousands of methods so that one doesn't has to subclass... > > Agree, the Morph protocol is bloated. And i don't like it too. That is a result of lifting features and properties up in inheritance chain. And i can imagine how it happens over time: - we have a morph.. - hurray! - can we have a morph with a border? - yes! Here BorderedMorph for you! - nice.. but can i use border in another subclass of Morph? - yes! Here borderStyle: property for you.. (and BorderedMorph is now useless) Or take a layout.. We could have , say, MorphWithLayout class. That introducing layouts. While other, simpler morph don't. Really, what layout you need in a morph that contains a plain rectangle fully covering its bounds? Or even 'having submorphs'. We could have MorphWithSubmorphs. Which could introduce submorphs concept. Separation of concerns. Good way to go. But if you need to have a morph that both has layout and border, then you are in trouble: you forced to do one of following: - make own Morph subclass, duplicating features of both.. or make a composition of submorphs that will represent both features, or... lift both features to the top of inheritance chain, getting bloat as result. Most of the times, most of things are achiveable through composition.. but some of them.. like drawing - apparently not. In any case i agree, that many features, that Morph proposing out of the box needs review and validation in terms, what if we isolate certain feature(s) in separate subclass and provide them via composition. Simpler, "subclassable" morphs suits me a lot better. > > Bloc looks like its taking some of the bad aspects of Morphic. > > One step at a time. You cannot fix all the problems of parent at once. The way how Bloc born, i think (i may be mistaken), it is a 'clean and lean' port of Morphic. But of course Morphic is huge monster, and porting such monster while rewriting its complex logic at the same time could be daunting hard. In any case, i think it is better. Let us hope, it will be even better. > Regards, > > Thierry > > -- Best regards, Igor Stasenko.

April 3, 2016

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

by Thierry Goubier

Le 03/04/2016 17:33, stepharo a Ã©crit : > 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. >> >> I see clearly point of Igor. And for me it feels very logical. >> With such design you can lively change clipping area and >> interaction area for any morph (element) on screen. >> >> >> In short, i see only two cases where indeed, morph requires a nothing >> of shapes to define: >> - clipping region(s) >> - ui interaction region(s) >> >> but for drawing? nooooo... really? who cares what you draw there? >> draw anything, in any possible way you see fit.. compose, decompose, >> recombine, blend and mix.. that's the whole purpose of drawing and be >> artistic and be able to express yourself in any possible way you want :) >> Why nailing and formalizing things that are tend to be hardly >> formalizable and more than that, unnecessary. >> That's my main concern about current design. > > I agree. > I do not see why people are forced to create a submorph just to change > the rendering. > If you want to change it dynamically you can for example pass a > different shape. I don't see the problem with subclassing a morph. The reverse: I feel like current Morphs are huge monsters of configurability and parameter blocks and properties and intricated code and thousands of methods so that one doesn't has to subclass... Simpler, "subclassable" morphs suits me a lot better. Bloc looks like its taking some of the bad aspects of Morphic. Regards, Thierry

April 3, 2016

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

by Igor Stasenko

On 3 April 2016 at 19:23, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > This means that any abstraction/wrapper around athens will fail. > > I would not say it like that. WIth decent effort you can do it. But the right question here: do you really need it? You missing some features for shapes? Good.. make new one(s) , just teach them how to draw themselves on Athens canvas and you done. For instance, for using shape in UI test it missing, #containsPoint: behavior. And for clipping, it missing clipOn: aCanvas during: aBlock behavior. So, you can choose to either extend basic protocol in Athens by implementing this feature(s) for all existing shapes, or introduce own shapes, polymorphic with AthensShape(s) but in addition implementing these protocols. Then you can use same shape for drawing, clipping and UI testing. Job done. You basically missing those two methods and you are done. And instead you inventing something that not only solves the problem, but puts a lot of restrictions on what you can draw using Block and how. > What if we would remove drawingShape and by default leave drawOn: method > to be empty. That way we would not put any constraints on rendering part. > user just gets athens canvas and can do whatever she wants. > > Well, a root morph cannot put any assumptions how his subclasses would want to draw themselves.. So, really, no assumptions means empty method. Sounds good to me. Well, it is empty, and just server as a placeholder indicating a protocol and a point of customization, nothing else. (Stef will most probably force you to put a nice comment there ;) > Instead we would have only clipping shape and event area shape. > What do you think? :) > That's what i proposing. What i think i already wrote in this thread :) It is up to you to accept or reject the idea. Or propose something even better and simpler. Or by any other participants of discussion. And why you surrender so fast? What if i am wrong? What is going on? Lets make it as best as we can, not 'as Igor says'. :) > Cheers, > Alex > > On Sun, Apr 3, 2016 at 6:04 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 3 April 2016 at 17:58, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >>> 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? >>> >>>> >> Nope. (see bottom of reply why) >> >> >>> .. 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 :) >>> 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. >>> >>> 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? :) >>> >> >> Nope. Because it would be beautiful, if your statements would be >> reflected in >> reality and by reality. >> In your example #defaultShape method, you simply isolating some behavior >> into a separate method. It does not changes anything. >> >> You want to achieve to be able to change shapes on the fly. Good. A >> honourable goal. And welcoming. No objections here. >> >> But can we achieve it without losing being able to change the color of >> shape on the fly. Please? :) >> The way you introducing it goes straightly into conflict with: i want to >> be able to draw anything, the way i feel and like. >> You proposing a bad trade: oh yeah, you wanted to change shapes on the >> fly.. good.. but at cost of unable to draw anything else than simple >> rectangles in simple order.. >> Well.. i am not buying such trade. Can you sweeten a deal? >> >> The point is, that shape is not the only thing you need to put into >> equation in order to get thing on the screen.. You also need paint. And >> that's the reason why you have >> fillPaint: (BlColorPaint new color: (Color yellow)); >> >> (lets put aside the hardcoding of color in unrelated place >> (defaultShape).. for the sake of example) >> but does that fully covers all and any possible ways and needs of drawing? >> Nope! Again not.. >> And voila, say welcome to composite "shapes" or "elements" or call it as >> you like it. >> But does that fully covers all and any possible ways you can draw >> something with Athens? >> Nope, it is not. Again. Sorry. You can achieve that only if you >> completely encode all possible operations and features provided by Athens >> using some kind of command pattern and put them in 'element' or >> 'compositeElement' or 'compositeOfCompositeElementsComposition' whatever. >> >> For instance, how you going to encode AthensPaintMode into your elements? >> I guess you will offer to kill it with your 'it is not used so often' >> knife. >> >> Can't you see that you basically creating a wrapper for all Athens >> feature set. >> I can tell you that you wasting effort: you cannot get anything extra by >> doing it. Except from extra complexity. >> And for what? Something that already there and can be used out of the box. >> >> If you don't like Athens API - go on, and change it. Make it better and >> more convenient to use. But encapsulating all possible combinations of all >> possible drawing operations? Good luck with that. >> >> >>> Cheers, >>> Alex >>> >>> On Sun, Apr 3, 2016 at 3:37 PM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> On 3 April 2016 at 16:20, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On 3 April 2016 at 15:28, Glenn CavarlÃ© <glenn(a)cavarle.fr> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Aliaksei Syrel wrote >>>>>> > However, in most UI of applications (in web, mobile) it is >>>>>> extremely rare >>>>>> > that clipping or event handling areas differ from drawing one >>>>>> (visual one >>>>>> > - >>>>>> > one that user sees in the end). >>>>>> >>>>>> It is the same for desktop UI (Qt, JavaFx,...). >>>>>> >>>>>> I think the misunderstanding come from "shape", so let us forget >>>>>> BlShape and >>>>>> concentrate on BlElement. >>>>>> >>>>>> In fact, using Bloc now, If we want a Rectangle with an clickable >>>>>> inner >>>>>> Circle, we have to defined 2 elements, the Rectangle one and the >>>>>> Circle one >>>>>> (subclass of BlElement or using script style). >>>>>> The CircleElement must be the child of the RectangleElement but we >>>>>> don't >>>>>> have to override any method or to rewire CircleElement events back to >>>>>> its >>>>>> parent, we just need to add an event listener to the CircleElement >>>>>> from >>>>>> where we want. >>>>>> It is the same with a Text in a Rectangle, we need a BlElement for >>>>>> the Text >>>>>> and another for the Rectangle in order to compose them and to >>>>>> position the >>>>>> Text in the Rectangle. >>>>>> >>>>>> For me its like defining a CircleButton in a RectanglePanel with any >>>>>> other >>>>>> ui libraries, i can do that by subclassing Panel or by using script >>>>>> style. >>>>>> But i have to manipulate 2 elements and it makes sense for me. >>>>>> >>>>>> Bloc does not provide user-friendly high-level abstractions at >>>>>> BlShape or >>>>>> BlElement level like BlCircleShape or BlCircleElement. >>>>>> I don't know if it is the right place to add them but it is clearly a >>>>>> point >>>>>> of misunderstanding when people uses Bloc. >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>> It seems to me that Bloc is not made to be used direclty as a graphical >>>>>> framework but it is a librarie to build more user-friendly graphical >>>>>> framework. >>>>>> Shape, Path, ... are implementations stuff, most of users should not >>>>>> care >>>>>> about that using a "framework". >>>>> >>>>> >>>>> Thanks for explanation.. >>>>> Now i have a hard time understanding, what is the purpose of so-called >>>>> 'element'. Element of what? What its role? >>>>> What its interaction between morphs and shapes, and what you see & >>>>> feel on the screen? >>>>> >>>>> From your description, what i can tell is that it is completely >>>>> unnecessary. >>>>> You have morphs to define hierarchy/composition. >>>>> And you can use shapes to define geometry for UI/clipping. >>>>> As for drawing - there's no need to put any constraints, you don't >>>>> have to even mention that there are shapes involved. It is indeed, an >>>>> implementation detail from that perspective, since you drawing things using >>>>> Athens, and it uses shapes to define affected regions. But that completely >>>>> orthogonal to what happens at UI level. >>>>> Thus, it is very surprising to me see following code snippet: >>>>> >>>>> >>>>> BlCell>>initialize >>>>> super initialize. >>>>> self >>>>> shape: >>>>> (BlShape new >>>>> fillPaint: (BlColorPaint new color: (Color yellow)); >>>>> path: BlRectanglePath new); >>>>> extent: self extent >>>>> >>>>> because it is really seems like encapsulation of what you gonna draw.. >>>>> and putting it into #initialize method in some form? >>>>> >>>>> And you lost me here.. That is complete nonsense.. from any >>>>> perspective. >>>>> Can i unsee this code, please? :) >>>>> >>>> >>>> <acid mode on> >>>> .. to me it feels like: okay, what we need to do, to prevent overrides >>>> of our beloved default #drawOn: method. >>>> >>>> And you talking about 'sophistication' after that? >>>> >>>> </acid mode off> >>>> >>>> >>>>> >>>>>> >>>>>> >>>>> PS: @Alex, what are the planned refactoring? I'm lost in the new >>>>>> intentions >>>>>> and in the roadmap of Bloc... >>>>>> Regards, >>>>>> Glenn. >>>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Glenn CavarlÃ© >>>>>> -- >>>>>> View this message in context: >>>>>> http://forum.world.st/bloc-shape-size-tp4887929p4888039.html >>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>> Nabble.com. >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

April 3, 2016

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

by Thierry Goubier

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. > > .. 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. > 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. Regards, Thierry

April 3, 2016

Spec SDL2 Bridge Help

by Rob Rothwell

Hello, I'm not sure if I'm right, but it looks like with Spec and SDL2 it is almost possible to compose native UI widgets from Pharo. This is very interesting to me, and I would like to volunteer as a laborer if someone could show me what to do. Obviously, a lot of the work would just be wrapping Spec around the platform API calls, which I imagine would [mostly] be a lot of trudging (once you knew what you were doing). If anyone knows what needs t be done (I really don't even know where to begin), and would be willing to mentor me, I would be very willing to do a lot of that grunt work. I've poked around in F-Script enough to know how to research Mac API calls, and there was a time in my VisualBasic days that knew how to do the same in Windows. I'm pretty good at slogging through things that just need to be done if I know what to do, but I would really need help getting started. Perhaps things aren't quite ready for this yet, but if and when they are and sheer (boring!) effort is needed, please feel free to contact me. Take care, Rob

April 3, 2016

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

by Aliaksei Syrel

This means that any abstraction/wrapper around athens will fail. What if we would remove drawingShape and by default leave drawOn: method to be empty. That way we would not put any constraints on rendering part. user just gets athens canvas and can do whatever she wants. Instead we would have only clipping shape and event area shape. What do you think? :) Cheers, Alex On Sun, Apr 3, 2016 at 6:04 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 3 April 2016 at 17:58, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > >> 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? >> >>> > Nope. (see bottom of reply why) > > >> .. 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 :) >> 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. >> >> 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? :) >> > > Nope. Because it would be beautiful, if your statements would be reflected > in > reality and by reality. > In your example #defaultShape method, you simply isolating some behavior > into a separate method. It does not changes anything. > > You want to achieve to be able to change shapes on the fly. Good. A > honourable goal. And welcoming. No objections here. > > But can we achieve it without losing being able to change the color of > shape on the fly. Please? :) > The way you introducing it goes straightly into conflict with: i want to > be able to draw anything, the way i feel and like. > You proposing a bad trade: oh yeah, you wanted to change shapes on the > fly.. good.. but at cost of unable to draw anything else than simple > rectangles in simple order.. > Well.. i am not buying such trade. Can you sweeten a deal? > > The point is, that shape is not the only thing you need to put into > equation in order to get thing on the screen.. You also need paint. And > that's the reason why you have > fillPaint: (BlColorPaint new color: (Color yellow)); > > (lets put aside the hardcoding of color in unrelated place > (defaultShape).. for the sake of example) > but does that fully covers all and any possible ways and needs of drawing? > Nope! Again not.. > And voila, say welcome to composite "shapes" or "elements" or call it as > you like it. > But does that fully covers all and any possible ways you can draw > something with Athens? > Nope, it is not. Again. Sorry. You can achieve that only if you completely > encode all possible operations and features provided by Athens using some > kind of command pattern and put them in 'element' or 'compositeElement' or > 'compositeOfCompositeElementsComposition' whatever. > > For instance, how you going to encode AthensPaintMode into your elements? > I guess you will offer to kill it with your 'it is not used so often' > knife. > > Can't you see that you basically creating a wrapper for all Athens feature > set. > I can tell you that you wasting effort: you cannot get anything extra by > doing it. Except from extra complexity. > And for what? Something that already there and can be used out of the box. > > If you don't like Athens API - go on, and change it. Make it better and > more convenient to use. But encapsulating all possible combinations of all > possible drawing operations? Good luck with that. > > >> Cheers, >> Alex >> >> On Sun, Apr 3, 2016 at 3:37 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> >>> On 3 April 2016 at 16:20, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> >>>> >>>> On 3 April 2016 at 15:28, Glenn CavarlÃ© <glenn(a)cavarle.fr> wrote: >>>> >>>>> Hi, >>>>> >>>>> Aliaksei Syrel wrote >>>>> > However, in most UI of applications (in web, mobile) it is extremely >>>>> rare >>>>> > that clipping or event handling areas differ from drawing one >>>>> (visual one >>>>> > - >>>>> > one that user sees in the end). >>>>> >>>>> It is the same for desktop UI (Qt, JavaFx,...). >>>>> >>>>> I think the misunderstanding come from "shape", so let us forget >>>>> BlShape and >>>>> concentrate on BlElement. >>>>> >>>>> In fact, using Bloc now, If we want a Rectangle with an clickable inner >>>>> Circle, we have to defined 2 elements, the Rectangle one and the >>>>> Circle one >>>>> (subclass of BlElement or using script style). >>>>> The CircleElement must be the child of the RectangleElement but we >>>>> don't >>>>> have to override any method or to rewire CircleElement events back to >>>>> its >>>>> parent, we just need to add an event listener to the CircleElement from >>>>> where we want. >>>>> It is the same with a Text in a Rectangle, we need a BlElement for the >>>>> Text >>>>> and another for the Rectangle in order to compose them and to position >>>>> the >>>>> Text in the Rectangle. >>>>> >>>>> For me its like defining a CircleButton in a RectanglePanel with any >>>>> other >>>>> ui libraries, i can do that by subclassing Panel or by using script >>>>> style. >>>>> But i have to manipulate 2 elements and it makes sense for me. >>>>> >>>>> Bloc does not provide user-friendly high-level abstractions at BlShape >>>>> or >>>>> BlElement level like BlCircleShape or BlCircleElement. >>>>> I don't know if it is the right place to add them but it is clearly a >>>>> point >>>>> of misunderstanding when people uses Bloc. >>>> >>>> >>>> >>>>> >>>>> >>>> It seems to me that Bloc is not made to be used direclty as a graphical >>>>> framework but it is a librarie to build more user-friendly graphical >>>>> framework. >>>>> Shape, Path, ... are implementations stuff, most of users should not >>>>> care >>>>> about that using a "framework". >>>> >>>> >>>> Thanks for explanation.. >>>> Now i have a hard time understanding, what is the purpose of so-called >>>> 'element'. Element of what? What its role? >>>> What its interaction between morphs and shapes, and what you see & feel >>>> on the screen? >>>> >>>> From your description, what i can tell is that it is completely >>>> unnecessary. >>>> You have morphs to define hierarchy/composition. >>>> And you can use shapes to define geometry for UI/clipping. >>>> As for drawing - there's no need to put any constraints, you don't have >>>> to even mention that there are shapes involved. It is indeed, an >>>> implementation detail from that perspective, since you drawing things using >>>> Athens, and it uses shapes to define affected regions. But that completely >>>> orthogonal to what happens at UI level. >>>> Thus, it is very surprising to me see following code snippet: >>>> >>>> >>>> BlCell>>initialize >>>> super initialize. >>>> self >>>> shape: >>>> (BlShape new >>>> fillPaint: (BlColorPaint new color: (Color yellow)); >>>> path: BlRectanglePath new); >>>> extent: self extent >>>> >>>> because it is really seems like encapsulation of what you gonna draw.. >>>> and putting it into #initialize method in some form? >>>> >>>> And you lost me here.. That is complete nonsense.. from any perspective. >>>> Can i unsee this code, please? :) >>>> >>> >>> <acid mode on> >>> .. to me it feels like: okay, what we need to do, to prevent overrides >>> of our beloved default #drawOn: method. >>> >>> And you talking about 'sophistication' after that? >>> >>> </acid mode off> >>> >>> >>>> >>>>> >>>>> >>>> PS: @Alex, what are the planned refactoring? I'm lost in the new >>>>> intentions >>>>> and in the roadmap of Bloc... >>>>> Regards, >>>>> Glenn. >>>>> >>>>> >>>>> >>>>> ----- >>>>> Glenn CavarlÃ© >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/bloc-shape-size-tp4887929p4888039.html >>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>> Nabble.com. >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

April 3, 2016

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

by Igor Stasenko

On 3 April 2016 at 18:30, stepharo <stepharo(a)free.fr> wrote: > > BlCell>>initialize > super initialize. > self > shape: > (BlShape new > fillPaint: (BlColorPaint new color: (Color yellow)); > path: BlRectanglePath new); > extent: self extent > > > Igor I could understand that if I want a clickable rectangle I have to > initialise it with such shape. > Now what I could not achieve was to get a circle drawn on it. > Sadly :) > > No, it doesn't sounds like that to me. It sounds like: - you can have your clickable rectangle, but only if you define a color of clickable region - "Color yellow". If you don't define color of clickable region - then system cannot derive from such incomplete data, what region is clickable and what not :) > Stef > > -- Best regards, Igor Stasenko.

April 3, 2016

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

by Igor Stasenko

On 3 April 2016 at 17:58, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > 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? > >> Nope. (see bottom of reply why) > .. 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 :) > 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. > > 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? :) > Nope. Because it would be beautiful, if your statements would be reflected in reality and by reality. In your example #defaultShape method, you simply isolating some behavior into a separate method. It does not changes anything. You want to achieve to be able to change shapes on the fly. Good. A honourable goal. And welcoming. No objections here. But can we achieve it without losing being able to change the color of shape on the fly. Please? :) The way you introducing it goes straightly into conflict with: i want to be able to draw anything, the way i feel and like. You proposing a bad trade: oh yeah, you wanted to change shapes on the fly.. good.. but at cost of unable to draw anything else than simple rectangles in simple order.. Well.. i am not buying such trade. Can you sweeten a deal? The point is, that shape is not the only thing you need to put into equation in order to get thing on the screen.. You also need paint. And that's the reason why you have fillPaint: (BlColorPaint new color: (Color yellow)); (lets put aside the hardcoding of color in unrelated place (defaultShape).. for the sake of example) but does that fully covers all and any possible ways and needs of drawing? Nope! Again not.. And voila, say welcome to composite "shapes" or "elements" or call it as you like it. But does that fully covers all and any possible ways you can draw something with Athens? Nope, it is not. Again. Sorry. You can achieve that only if you completely encode all possible operations and features provided by Athens using some kind of command pattern and put them in 'element' or 'compositeElement' or 'compositeOfCompositeElementsComposition' whatever. For instance, how you going to encode AthensPaintMode into your elements? I guess you will offer to kill it with your 'it is not used so often' knife. Can't you see that you basically creating a wrapper for all Athens feature set. I can tell you that you wasting effort: you cannot get anything extra by doing it. Except from extra complexity. And for what? Something that already there and can be used out of the box. If you don't like Athens API - go on, and change it. Make it better and more convenient to use. But encapsulating all possible combinations of all possible drawing operations? Good luck with that. > Cheers, > Alex > > On Sun, Apr 3, 2016 at 3:37 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 3 April 2016 at 16:20, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> >>> On 3 April 2016 at 15:28, Glenn CavarlÃ© <glenn(a)cavarle.fr> wrote: >>> >>>> Hi, >>>> >>>> Aliaksei Syrel wrote >>>> > However, in most UI of applications (in web, mobile) it is extremely >>>> rare >>>> > that clipping or event handling areas differ from drawing one (visual >>>> one >>>> > - >>>> > one that user sees in the end). >>>> >>>> It is the same for desktop UI (Qt, JavaFx,...). >>>> >>>> I think the misunderstanding come from "shape", so let us forget >>>> BlShape and >>>> concentrate on BlElement. >>>> >>>> In fact, using Bloc now, If we want a Rectangle with an clickable inner >>>> Circle, we have to defined 2 elements, the Rectangle one and the Circle >>>> one >>>> (subclass of BlElement or using script style). >>>> The CircleElement must be the child of the RectangleElement but we don't >>>> have to override any method or to rewire CircleElement events back to >>>> its >>>> parent, we just need to add an event listener to the CircleElement from >>>> where we want. >>>> It is the same with a Text in a Rectangle, we need a BlElement for the >>>> Text >>>> and another for the Rectangle in order to compose them and to position >>>> the >>>> Text in the Rectangle. >>>> >>>> For me its like defining a CircleButton in a RectanglePanel with any >>>> other >>>> ui libraries, i can do that by subclassing Panel or by using script >>>> style. >>>> But i have to manipulate 2 elements and it makes sense for me. >>>> >>>> Bloc does not provide user-friendly high-level abstractions at BlShape >>>> or >>>> BlElement level like BlCircleShape or BlCircleElement. >>>> I don't know if it is the right place to add them but it is clearly a >>>> point >>>> of misunderstanding when people uses Bloc. >>> >>> >>> >>>> >>>> >>> It seems to me that Bloc is not made to be used direclty as a graphical >>>> framework but it is a librarie to build more user-friendly graphical >>>> framework. >>>> Shape, Path, ... are implementations stuff, most of users should not >>>> care >>>> about that using a "framework". >>> >>> >>> Thanks for explanation.. >>> Now i have a hard time understanding, what is the purpose of so-called >>> 'element'. Element of what? What its role? >>> What its interaction between morphs and shapes, and what you see & feel >>> on the screen? >>> >>> From your description, what i can tell is that it is completely >>> unnecessary. >>> You have morphs to define hierarchy/composition. >>> And you can use shapes to define geometry for UI/clipping. >>> As for drawing - there's no need to put any constraints, you don't have >>> to even mention that there are shapes involved. It is indeed, an >>> implementation detail from that perspective, since you drawing things using >>> Athens, and it uses shapes to define affected regions. But that completely >>> orthogonal to what happens at UI level. >>> Thus, it is very surprising to me see following code snippet: >>> >>> >>> BlCell>>initialize >>> super initialize. >>> self >>> shape: >>> (BlShape new >>> fillPaint: (BlColorPaint new color: (Color yellow)); >>> path: BlRectanglePath new); >>> extent: self extent >>> >>> because it is really seems like encapsulation of what you gonna draw.. >>> and putting it into #initialize method in some form? >>> >>> And you lost me here.. That is complete nonsense.. from any perspective. >>> Can i unsee this code, please? :) >>> >> >> <acid mode on> >> .. to me it feels like: okay, what we need to do, to prevent overrides of >> our beloved default #drawOn: method. >> >> And you talking about 'sophistication' after that? >> >> </acid mode off> >> >> >>> >>>> >>>> >>> PS: @Alex, what are the planned refactoring? I'm lost in the new >>>> intentions >>>> and in the roadmap of Bloc... >>>> Regards, >>>> Glenn. >>>> >>>> >>>> >>>> ----- >>>> Glenn CavarlÃ© >>>> -- >>>> View this message in context: >>>> http://forum.world.st/bloc-shape-size-tp4887929p4888039.html >>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>> Nabble.com. >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

April 3, 2016

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

by stepharo

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. > > I see clearly point of Igor. And for me it feels very logical. > With such design you can lively change clipping area and > interaction area for any morph (element) on screen. > > > In short, i see only two cases where indeed, morph requires a nothing > of shapes to define: > - clipping region(s) > - ui interaction region(s) > > but for drawing? nooooo... really? who cares what you draw there? > draw anything, in any possible way you see fit.. compose, decompose, > recombine, blend and mix.. that's the whole purpose of drawing and be > artistic and be able to express yourself in any possible way you want :) > Why nailing and formalizing things that are tend to be hardly > formalizable and more than that, unnecessary. > That's my main concern about current design. I agree. I do not see why people are forced to create a submorph just to change the rendering. If you want to change it dynamically you can for example pass a different shape. > > -- > Best regards, > Igor Stasenko.

April 3, 2016

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

by stepharo

> BlCell>>initialize > super initialize. > self > shape: > (BlShape new > fillPaint: (BlColorPaint new color: (Color yellow)); > path: BlRectanglePath new); > extent: self extent > > Igor I could understand that if I want a clickable rectangle I have to initialise it with such shape. Now what I could not achieve was to get a circle drawn on it. Sadly :) Stef

April 3, 2016