On 3 April 2016 at 19:23, Aliaksei Syrel <alex.sy...@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 <siguc...@gmail.com> wrote: > >> >> >> On 3 April 2016 at 17:58, Aliaksei Syrel <alex.sy...@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 <siguc...@gmail.com> >>> wrote: >>> >>>> >>>> >>>> On 3 April 2016 at 16:20, Igor Stasenko <siguc...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On 3 April 2016 at 15:28, Glenn Cavarlé <gl...@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.
