> > 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? .. 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? :) Cheers, Alex On Sun, Apr 3, 2016 at 3:37 PM, Igor Stasenko <[email protected]> wrote: > > > On 3 April 2016 at 16:20, Igor Stasenko <[email protected]> wrote: > >> >> >> On 3 April 2016 at 15:28, Glenn Cavarlé <[email protected]> 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. >
