If you want to change clicking behaviour you need to override one
single method.
Everything you wrote with unreadable amount of characters is for nothing.
All mentioned stuff is possible.
On Apr 3, 2016 10:30 AM, "Igor Stasenko" <[email protected]
<mailto:[email protected]>> wrote:
On 3 April 2016 at 10:18, Tudor Girba <[email protected]
<mailto:[email protected]>> wrote:
Hi Igor,
Thanks for this nice description :).
Indeed, the Shape in Bloc is primarily a clipping shape that
knows how to draw the path around and to fill itself. Of
course, it also handles the interaction.
When you want to have a composition, you are encouraged to
create multiple elements (morphs). This is a way to handle
both more complicated interaction and more complicated
drawing. Of course, you can still override the drawing method
and draw whatever you want on it, but we would rather have a
simple composition.
The disadvantage of this design is that indeed, is that it is
not sophisticated. The advantage of this design is that it is
not sophisticated :) and you get only one tree of compositions
for the elements without another level of composition at the
shape level. The main reason we went this route is because we
want Bloc to pose as little constraints for the things built
on top as possible without losing power.
Does this make sense for you?
It makes sense, sure thing.
But it does not solves the problem.
As i explained before, a single shape cannot serve as both
clipping, UI handling and drawing all together. Because it is
three separate roles, which is good if they coincide, but causing
a lot of problems, when they are not.
It is not matters how you compose or decompose shapes.. there is
simply no composition which can turn rectangle into, lets say circle.
it simply impossible to construct required clipping shape, or UI
shape from set of drawing shapes, in case when they are completely
different from each other.
For instance if i want morph with rectangular appearance
(rectangle shape) to respond on clicks only within circular
subregion inside that rectangle, i will be forced to create a
submorph and then rewire event handling back to its parent. And
that happens every time i need a different shape for mouse clicks
than shape for drawing. Now add clipping here... and you will get
a nightmare of bells and whistles, composing and whatsnot.
As for 'sophisticated'.. let see:
so, in my proposition, i do:
- draw rectangle and circle inside
- define that circle as UI shape
- define that rectangle as clipping shape
done.
In your design, i have to:
- make a morph with rectangular shape
- create submorph with circular shape
- wire clicking of a submorph to propagate event to its parent
or think about some kind of composition.. composing what with what?
does it union of circle and rectangle? or intersection? depending
the way how you composing those two shapes you receive one or
another outcome..
and that event wiring is extra work..
So, it may look that what i proposing is more sophisticated..
But i just wanna see a separate roles taking own places, nothing else.
I do not inventing new concepts, that wasn't there before:
- you need clipping,
- you need drawing
- you need UI handling
You see, it is not a framework, that forcing you to be
'sophisticated' .. it is domain itself. It draws a clear border
between things that are optional and things that are absolutely
necessary, since they are separate concepts and roles.
You simply cannot represent an infinite dimension of drawing
compositions by a composition of UI elements. Only the simplest
cases..
It is big mistake to imply that anything that you drawing on
screen must be a full-blown UI element (which is morph is) or
their composition.
It makes you quite limited in terms of what you can draw and what not.
Morph is UI building brick.. but it is not graphical building
brick.. making such parallel gives more troubles than it solves.
To me concept where morph==shape==clipping shape==ui shape is just:
- you can have bike of any color, as long as it's black.
Can you enlighten me, what composition of black bikes can result
in a green one?
Cheers,
Doru
> On Apr 3, 2016, at 6:38 AM, Igor Stasenko
<[email protected] <mailto:[email protected]>> wrote:
>
> Oh, yeah.. i missed one more kind of shape, you may want to
introduce:
> - clipping shape.
>
> For optimizing drawing operations, you may want to define a
region, which guarantees, that anything you paint, nothing
outside defined region will affect the screen. Because else,
you will allow morph to render anywhere and therefore, it is
really hard for UI subsystem to account damage on the screen.
> But once you define such shape, then you can clearly tell,
which portion of the screen may or may not be damaged and
therefore act accordingly.
>
> So, overall when we talking about shapes, we need to talk
about three different kinds of them:
>
> - UI interaction shape
> - clipping shape
> - shape(s) used to draw
>
> those three may or may not coincide into single one,
depending on complexity and what you wanna do..
> But they can be completely different from each other and in
order to avoid confusion and frustration, i would really
introduce them in such manner, that users have clear vision on
what happens with their morphs and how to achieve what they want.
>
> Clearly, a single #shape: is not enough, if you want a
non-conflicting representation of these concepts in UI.
>
>
> On 3 April 2016 at 07:15, Igor Stasenko <[email protected]
<mailto:[email protected]>> wrote:
>
>
> On 2 April 2016 at 20:59, stepharo <[email protected]
<mailto:[email protected]>> wrote:
>
>
> Le 2/4/16 17:31, Aliaksei Syrel a écrit :
>> You don't want to draw a shape, you configure it. Shape can
not be drawn, it is not an AthensPath.
>>
>> cell shape: (BlShape new
>> path: BlCirclePath new;
>> strokePaint: (BlStrokePaint new
>> paint: Color blue;
>> width: 1)).
>> cell extent: 50@50.
>>
>
> But this is not what I want! As I mentioned in a mail that
was sent but never arrived.
> I want a square and this is why I did
>
> BlCell>>initialize
> super initialize.
> self
> shape:
> (BlShape new
> fillPaint: (BlColorPaint new color: (Color
yellow));
> path: BlRectanglePath new);
> extent: self extent
>
>
> then I want to draw something extra this is why I overrode
drawOnAthensCanvas: aCanvas
>
> Now I stop but I find bloc too complex.
>
> Sorry but I cannot lose time like that and just get
frustrated at the end.
> I will use the athens canvas directly and stay in morph for now.
>
>
> I think there's a bit of misconception.
> In Athens, shape representing any area you wanna fill with
paint. Period.
> It can be of any complexity, self-intersecting yadda yadda..
the main point is that it defines a region(s), that going to
be filled with chosen paint during draw operation.
> From perspective of morphs, as UI elements, most of them
require some shape(s) to represent themselves on the screen.
But there are morphs, that while still taking part in UI,
don't need any shapes since they never drawn on the screen.
> Another point is that nowhere said that morph can be
represented by a one and only one shape period. Because as in
your case, you want to, say, draw rectangle with paint A, and
circle with paint B, then you basically need two different
shapes (overlapping or not - not really matters) to represent
morph on the screen.
>
> So, the first point in misconception comes from 'self shape:'..
> It is wrong from that perspective, because it is all fine,
when morph using only single shape to represent itself.. but
when you need multiple shapes, you are in trouble. It at least
misleading, because provoking you to think that there can be
only one.
>
> Then you need to invent a 'composite shape' that basically a
collection of shapes for a single morph, that will represent
it on the screen.
>
> A tangent to that, is that since most of morphs has mostly
static geometry/topology and changing it very rarely and much
less often comparing to drawing same shape(s) over and over
again, it is right thing to define and initialize shape(s) and
reuse them later in #draw method. Since you don't change
shape(s), you don't have to generate new object(s).
> From that perspective, this is nice, resource saving, approach.
> But let us not forget, that this is just a 'statistical
observation' and hence good to be a default setup. But it
should not dictate you the rule(s).
> You should still be able to define shape(s) on the fly or
change it on the fly, dynamically.
>
> Another problematic is that you may want to use different
shapes for
> a) painting morph on screen
> b) defining geometry of the morph for UI interactions.
> As an example, let say, you want a rectangle with circle in
centre on the screen, but also want morph to react on mouse
over/clicks only if mouse cursor is inside a circle, but not
when it's over an area covered by rectangle.
>
> What it means, that from UI perspective, you want from morph
to define its shape, lets call it 'UI interaction shape'.. and
from that perspective 'self shape:' is a good choice. But as
example says, it has nothing to do with 'drawing shape(s)',
which may or may not coincide with shape you using for UI
interaction(s).
>
> Because it defines an area, where UI stuff could happen. And
indeed, you really need one, and only one. You don't need
multiple shapes there, since it serves to answer a simple
question: 'are my mouse in interesting region or not'?.
> Like in your case, when you having box with circle inside ,
which is two shapes, but only one shape that can define an
interesting region, it could be:
> - intersection of
> - union
> - subtraction
>
> And that could be completely different from shape(s) you may
need to draw it on the screen.
>
> Stef
>
>> On Apr 2, 2016 4:57 PM, "stepharo" <[email protected]
<mailto:[email protected]>> wrote:
>> Hi
>>
>> I want a square morph with a circle or a line at 45 degree
inside
>> Now I do not get it.
>>
>> I thought that I needed to specialize drawOnAthensCanvas:
so I did
>>
>> BlCell >> drawOnAthensCanvas: aCanvas
>>
>> super drawOnAthensCanvas: aCanvas.
>> aCanvas
>> drawShape: (BlShape new
>> strokePaint:
>> (BlStrokePaint new
>> paint: (BlColorPaint new color: (Color blue));
>> width: 15);
>> path: BlCirclePath new).
>>
>> Now I do not know how I can specify a shape size
>>
>> So I will use another API than drawShape:
>>
>> Stef
>>
>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
>
> --
> Best regards,
> Igor Stasenko.
--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com <http://www.feenk.com>
"Reasonable is what we are accustomed with."
--
Best regards,
Igor Stasenko.
