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". 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.
