[Pharo-dev] [bloc] shape size?

Igor Stasenko siguctua at gmail.com
Sun Apr 3 07:31:28 EDT 2016


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

> Hello Igor
>
> I would like to apologize for my bad tone in previous email. I
> misunderstood your good will to help and improve design by finding special
> cases that we didn't manage to cover. I indeed would like to show you that
> design sounds.
>
> Let's play with more concrete examples. To start let's take one mentioned
> by you, about rectangle morph that answers to events only inside a circle.
>
> I will create a repo for PUBLIC bloc experiments so that all of us could
> try it in practice.
>
> Your help is highly appreciated and we are happy to see you :)
>
Thank you, Aliaksei. If you have an impression that i came here to troll
you or to argue just for the sake of arguing and wasting your time, please
trust me, i am not.
I spent a lot of time thinking about this stuff and making it and
discussing it over and over again with many people, including Alain, Stef
and others.. and so, i am not a stranger that passing by, i honestly want
to see it fly, be smooth and elegant , close to perfect, but not crawl on a
set of kludges.


> Cheers
>
>
> 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.
>



-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160403/2e3f486b/attachment.html>


More information about the Pharo-dev mailing list