[Pharo-dev] [bloc] shape size?

Igor Stasenko 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:
>
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160403/4f12f760/attachment.html>


More information about the Pharo-dev mailing list