On 3 April 2016 at 16:20, Igor Stasenko <siguctua@gmail.com> wrote:

On 3 April 2016 at 15:28, Glenn Cavarl�� <glenn@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.