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? :)
>
>
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.
