Layout in bloc

> On Aug 28, 2016, at 5:18 AM, Aliaksei Syrel <[hidden email]> wrote:
>
> Hi
>
> Thanks for the example. Exactly, ability to have elements that are visible but not participate in layout is very important. But first I would like to describe bloc layout a bit more.
>
> ---------------------------------
> If you think for a second about the meaning of "layout" you would realize that layout is just "the way in which the parts of something are arranged or laid out". So, actually, layout is all about determining the positions of elements within the parent (origin of bounds). However, real world is a bit more complicated, especially when it comes to visual elements. In our world we must also compute size (extent) of every element before actually laying it out. Bad news is that size depends on layout type and layout constraints (match parent, fit content, take exact size) that may depend rather on children or parent.
>
> In Bloc the whole process is divided in two parts: measurement and layout. They are completely separated and do not overlap.
>
> During measurement step we iterate over the whole tree and depending on layout and constraints only compute extent of every element. For optimisation purposes layout caches previous extent and if during new measurement step it does not change, we stop, skipping children. There is a rule: if child's constraints didn't change and if child's measurement bit is not dirty and if parent's extent is the same child will have the same extent.
>
> Than comes layout step. Because we already measured all extents we can easily determine positions within the parent, and logic is very simple.
> ---------------------------------
>
> Now let's think about visibility and visible: setter. What argument should it be? How do we encode visibility. In Morphic it is a Boolean. However, in real world it is a bit more complicated.
>
> Sometimes we want an element to be completely gone, it is not visible and does not take any space within the parent and does not participate in layout.
> Sometimes we want an element to be hidden, it is not visible but it still occupies space within the parent (it is just empty) and do participate in layout.
> Sometimes we want an element to be floating, it is visible but does not occupy any space and does not participate in layout. However, a floating element must be measured (extent computed), we just do not want to compute its position and simply let user set it manually.
>
> To conclude, instead of Boolean in Bloc visibility is defined by BlVisibility object.
> --------------------------------
>
> Floating mode is exactly what you want, Alex. It can be set easily:
> txt constraints beFloating.
>
> However, I just checked and it does not work. Looks like this feature was removed during last iteration. I find this feature is a huge step forward, but now we are many steps back :(
>
>
> Cheers,
> Alex
>
> On 28 August 2016 at 02:24, Alexandre Bergel <[hidden email]> wrote:
> Hi!
>
> I am working on a popup support in Bloc and I am facing a problem. Consider the following code:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>         space := BlSpace new.
>         space root layout: BlLinearLayout horizontal.
>         10
>                 timesRepeat: [ | e |
>                         e := (BlRectangle new extent: 20 @ 20) asElement.
>                         e background: Color random.
>                         space root addChild: e ].
>         space root children withIndexDo: [ :e :index | e translateBy: (index * 30) @ 10 ].
>
>         space root children do: [ :e |
>                 e
>                 addEventHandler:
>                         (BlEventHandler
>                                 on: BlMouseEnterEvent
>                                 do: [ :evt |
>                                                 | txt |
>                                                 txt := BlText new
>                                                         position: evt position;
>                                                         fill: Color red;
>                                                         text: 'Hello World'.
>
>                                                 e parent addChild: txt ]).
>
>                  ].
>         space show
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> If you uncomment the second line (“space root layout:…”), then the string hello world is added text to the element in which the mouse enter. With the layout, the string is added at the end of the line.
>
> I like very much the idea of having the layout applied when elements are added (even I suspect we may have scalability issues very soon), but in that situation, this is not wished.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

> On Aug 28, 2016, at 5:18 AM, Aliaksei Syrel <[hidden email]> wrote:
>
> Hi
>
> Thanks for the example. Exactly, ability to have elements that are visible but not participate in layout is very important. But first I would like to describe bloc layout a bit more.
>
> ---------------------------------
> If you think for a second about the meaning of "layout" you would realize that layout is just "the way in which the parts of something are arranged or laid out". So, actually, layout is all about determining the positions of elements within the parent (origin of bounds). However, real world is a bit more complicated, especially when it comes to visual elements. In our world we must also compute size (extent) of every element before actually laying it out. Bad news is that size depends on layout type and layout constraints (match parent, fit content, take exact size) that may depend rather on children or parent.
>
> In Bloc the whole process is divided in two parts: measurement and layout. They are completely separated and do not overlap.
>
> During measurement step we iterate over the whole tree and depending on layout and constraints only compute extent of every element. For optimisation purposes layout caches previous extent and if during new measurement step it does not change, we stop, skipping children. There is a rule: if child's constraints didn't change and if child's measurement bit is not dirty and if parent's extent is the same child will have the same extent.
>
> Than comes layout step. Because we already measured all extents we can easily determine positions within the parent, and logic is very simple.
> ---------------------------------
>
> Now let's think about visibility and visible: setter. What argument should it be? How do we encode visibility. In Morphic it is a Boolean. However, in real world it is a bit more complicated.
>
> Sometimes we want an element to be completely gone, it is not visible and does not take any space within the parent and does not participate in layout.
> Sometimes we want an element to be hidden, it is not visible but it still occupies space within the parent (it is just empty) and do participate in layout.
> Sometimes we want an element to be floating, it is visible but does not occupy any space and does not participate in layout. However, a floating element must be measured (extent computed), we just do not want to compute its position and simply let user set it manually.
>
> To conclude, instead of Boolean in Bloc visibility is defined by BlVisibility object.
> --------------------------------
>
> Floating mode is exactly what you want, Alex. It can be set easily:
> txt constraints beFloating.
>
> However, I just checked and it does not work. Looks like this feature was removed during last iteration. I find this feature is a huge step forward, but now we are many steps back :(
>
>
> Cheers,
> Alex
>
> On 28 August 2016 at 02:24, Alexandre Bergel <[hidden email]> wrote:
> Hi!
>
> I am working on a popup support in Bloc and I am facing a problem. Consider the following code:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>         space := BlSpace new.
>         space root layout: BlLinearLayout horizontal.
>         10
>                 timesRepeat: [ | e |
>                         e := (BlRectangle new extent: 20 @ 20) asElement.
>                         e background: Color random.
>                         space root addChild: e ].
>         space root children withIndexDo: [ :e :index | e translateBy: (index * 30) @ 10 ].
>
>         space root children do: [ :e |
>                 e
>                 addEventHandler:
>                         (BlEventHandler
>                                 on: BlMouseEnterEvent
>                                 do: [ :evt |
>                                                 | txt |
>                                                 txt := BlText new
>                                                         position: evt position;
>                                                         fill: Color red;
>                                                         text: 'Hello World'.
>
>                                                 e parent addChild: txt ]).
>
>                  ].
>         space show
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> If you uncomment the second line (“space root layout:…”), then the string hello world is added text to the element in which the mouse enter. With the layout, the string is added at the end of the line.
>
> I like very much the idea of having the layout applied when elements are added (even I suspect we may have scalability issues very soon), but in that situation, this is not wished.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>