[Pharo-dev] [bloc] shape size?

Igor Stasenko siguctua at gmail.com
Sun Apr 3 05:47:03 EDT 2016


On 3 April 2016 at 12:08, Aliaksei Syrel <alex.syrel at gmail.com> wrote:

> If you want to change clicking behaviour you need to override one single
> method.
>
it is not about just clicking behavior. Sure i can override every single
method to get behavior i want, at any point in system i need.
Then what is purpose of making any design, if it all goes down to 'oh.. if
you don't like something , just go and do it youself'?
Seriously?

> Everything you wrote with unreadable amount of characters is for nothing.
>
> Haha.. If you can't read something, it does not means, that there's
nothing. It just you cannot read.


> All mentioned stuff is possible.
>
Details, that statement requires. You seem don't want to demonstrate that
your concept is sound. Because i wanna see how it goes.. So far i have
doubts about it, which i tried to formulate in previous posts.. i may not
understand in it something, something you understand.. and i wanna see
where i wrong.
And in response i got nothing, no arguments, zero. This is exactly, what
called 'nothing'.


> On Apr 3, 2016 10:30 AM, "Igor Stasenko" <siguctua at gmail.com> wrote:
>
>>
>>
>> On 3 April 2016 at 10:18, Tudor Girba <tudor at tudorgirba.com> 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 <siguctua at gmail.com> 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 <siguctua at gmail.com> wrote:
>>> >
>>> >
>>> > On 2 April 2016 at 20:59, stepharo <stepharo at free.fr> 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 at 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" <stepharo at free.fr> 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
>>> www.feenk.com
>>>
>>> "Reasonable is what we are accustomed with."
>>>
>>>
>>>
>>
>>
>> --
>> 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/c81aa830/attachment.html>


More information about the Pharo-dev mailing list