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.
