[Pharo-dev] [bloc] shape size?
siguctua at gmail.com
Sun Apr 3 09:37:27 EDT 2016
On 3 April 2016 at 16:20, Igor Stasenko <siguctua at gmail.com> wrote:
> On 3 April 2016 at 15:28, Glenn Cavarlé <glenn at cavarle.fr> wrote:
>> Aliaksei Syrel wrote
>> > However, in most UI of applications (in web, mobile) it is extremely
>> > that clipping or event handling areas differ from drawing one (visual
>> > -
>> > 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
>> 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
>> (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
>> 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
>> 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
>> 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
> 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:
> super initialize.
> (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...
>> Glenn Cavarlé
>> View this message in context:
>> Sent from the Pharo Smalltalk Developers mailing list archive at
> Best regards,
> Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev