[Demo] Creating Bloc Widgets with Pharo

Bloc is ready for your experiments. Here is my first one.
Please let me know what and how to improve.

Bloc allows for the creation of beautiful widgets.
Here is a panel containing collapsible subpanels
that can be reordered with drag-and-drop.

https://vimeo.com/235934701

Stephan

Thanks Stefan
I will have a look.
Now how do you validate the API of your widgets.
I think that write test is a really because in that it will force us
to have fully scriptable widgets.

stef


On Thu, Sep 28, 2017 at 6:04 PM, Stephan Eggermont <[hidden email]> wrote:

I was wondering how we could provide a "better" interface for object.

For example why a BlElement cannot get
invisible and visible in addition to visibility: BlVisibility visible.

Stef

On Thu, Sep 28, 2017 at 9:03 PM, Stephane Ducasse
<[hidden email]> wrote:

On 28-09-17 21:03, Stephane Ducasse wrote:
> Now how do you validate the API of your widgets.

Good question. In Morphic I had everything centralized in the Morph.
The advantage is that it is clear what influences what, the disadvantage
is that it easily results in very complex code. Here I have event
handling spread over multiple objects. That gives here a better
separation of concerns. The pane itself handles clicking, the
dragInteraction object the drag and drop. Separating these two works,
but in a more complex application there could be e.g. multiple drag and
drop relationships.

> I think that write test is a really because in that it will force us
> to have fully scriptable widgets.

Indeed. At the moment I am still trying to find out how I want to
distribute responsibilities. I welcome ideas on how to improve this.

And of course I would like the dropping to also work on the last position.

Stephan

On 28-09-17 21:07, Stephane Ducasse wrote:
> For example why a BlElement cannot get
> invisible and visible in addition to visibility: BlVisibility visible.

It can, and if we do that systematically we end up with a BlElement with
a thousand methods. There are so many aspects that an element might need
to handle. Handling children, layout, styling, drawing, fonts, events,
visibility. Where should the border be?

One thing I noted is that in Bloc we don't have a way to decide where to
add a dropped element in a parent that has a specified layout. In
Morphic that is also a responsibility of the layout.

Stephan

On 29/09/17 00:51, Igor Stasenko wrote:
> Stephan , you said you cannot replace the last one in the video.
> I think you can have an easy solution: you should treat a pane that you
> are currently over - the one you are going to replace, so if you drag
> over something which is not placeholder,
> then it should automatically be shifted and replaced by placeholder.

Thanks.

This works. I forgot that there is always one more dropping place
possible than there are elements

dragEvent: anEvent
        | dragOver |
        anEvent consumed: true.
        dragOver := inspector children first.
        inspector childrenDo: [ :c |
                c boundsInSpace center y < (anEvent position y + dragOffset y) ifTrue: [
                        dragOver := c ] ].
        (dragOver ~= placeHolder ) ifTrue: [
                (inspector childIndexOf: placeHolder) > 0 ifTrue: [inspector
removeChild: placeHolder].
                inspector children last boundsInSpace bottom < (anEvent position y +
dragOffset y) ifTrue: [
                        inspector addChild: placeHolder at: (1+(inspector childIndexOf:
dragOver))]
                ifFalse: [
  inspector addChild: placeHolder at: (inspector childIndexOf:
dragOver)]].
   anEvent currentTarget position: (anEvent position - dragOffset).

Hi Stephan,

Why not having PrInspector>>open ?
How can I open your inspector?

Cheers,
Alexandre

But exposing internals of the encoding is not really good either.
Graphical objects are complex still forcing all the logic to be set by
client is a way to make that we will also get some spaghetti.

Look In Morphic at the icon in the menu, we ended up have wrong
reference all over the places.
Just because the API was not good and did not encapsulate enough behavior.

Stef

On Thu, Sep 28, 2017 at 11:56 PM, stephan <[hidden email]> wrote:

My suggestion is write tests and after try to build a Spec adapter.
The spec adpater will be a really good client. Because with Boc the
adapter should not exist at runtime.
It should just be there for the registration but not a middle man like now.

Stef

On Thu, Sep 28, 2017 at 11:44 PM, stephan <[hidden email]> wrote:

On 29/09/17 13:20, Alexandre Bergel wrote:
> Why not having PrInspector>>open ?
> How can I open your inspector?

Indeed, something like

PrInspector class>>open
        <example>
        |space|
        space := BlSpace new.
        space extent: 160@180.
        space root addChild: self new.
        space show