[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 <stephan@stack.nl> wrote:
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.
Stephan
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 <stepharo.self@gmail.com> wrote:
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 <stephan@stack.nl> wrote:
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.
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
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. Cheers :) On 29 September 2017 at 00:56, stephan <stephan@stack.nl> wrote:
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
-- Best regards, Igor Stasenko.
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).
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 <stephan@stack.nl> wrote:
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 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
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 <stephan@stack.nl> 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 Fri, Sep 29, 2017 at 12:04 AM, Stephan Eggermont <stephan@stack.nl> wrote:
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.
Stephan
Thanks Stephan. That provides a good insight into using Bloc. More encouragement to try it out myself. cheers -ben
Hi Stephan, Why not having PrInspector>>open ? How can I open your inspector? Cheers, Alexandre
On Sep 28, 2017, at 1:04 PM, Stephan Eggermont <stephan@stack.nl> wrote:
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.
Stephan <Presentations-Widgets.st><ExpanderPanel.png>
participants (6)
-
Alexandre Bergel -
Ben Coman -
Igor Stasenko -
stephan -
Stephan Eggermont
-
Stephane Ducasse