Roassal-ComplexShape kick-off

List overview All Threads
Download

newer

older

Video uploads PharoConf & MooseDay...

Bug in Roassal?

Juraj Kubelka

10 Apr 2013 10 Apr '13

4:03 a.m.

Hi all, Hi Doru! There is the kick-off of ComplexShape implementation in Roassal. If you file-in the attached code into https://ci.inria.fr/moose/job/moose-latest-dev-4.8/, you will be able to play with it a bit. There is ROGridBuilderTest test class with two examples. Doru, I suppose you are almost only one who manage Mondrian's complex shapes. Would you please examine the code and give me your opinion? Thank you a lot. … Of course any one can give me some feedback :-) I would appreciate it. For now I focused to do UML Class diagram. I know about blue-prints which can be done similar way. I have not seen other complex shapes. So there is an open space for other requirements which can impact interface and design. Implementation breaks several tests because of change in ROContainer>>encompassingNestedRectangle. I removed a default extent (5@5) which is not wanted. I will fix the tests later when the implementation will be accepted. Thank you for any response or question, Jura [image: Imágenes integradas 1]

Attachments:

ROGridLayoutclass-onwithGapwithLineItemsCount.st (application/octet-stream — 797 bytes)
ROMondrianViewBuilder-nodesusing.st (application/octet-stream — 506 bytes)
ROMondrianViewBuilder-nodeusing.st (application/octet-stream — 277 bytes)
ROShapeclass-chainedCopy.st (application/octet-stream — 188 bytes)
attachment.htm (text/html — 1.4 KB)
roassal-complexshape-export-of-roshape.png (image/png — 128.2 KB)
Roassal-ComplexShape-Tests.st (application/octet-stream — 5.4 KB)
Roassal-ComplexShape.st (application/octet-stream — 5.5 KB)
ROContainer-encompassingNestedRectangle.st (application/octet-stream — 380 bytes)

Show replies by date

Tudor Girba

10 Apr 10 Apr

7:57 a.m.

Hi Juraj, Great to see this starting. To make collaboration easier please do the following: - create a separate repository on SmalltalkHub - put your Roassal extensions there - send a Gofer script to load this code easily in a Moose image. (ask specific questions if you do not find out how to do it) In the meantime, I will try like it is now. Cheers, Doru On Wed, Apr 10, 2013 at 4:03 AM, Juraj Kubelka <juraj.kubelka(a)gmail.com>wrote;wrote:

...

-- www.tudorgirba.com "Every thing has its own flow"

Juraj Kubelka

4:27 p.m.

...

-- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

4:30 p.m.

Thanks! Now, it will be easier to review :) Doru On Wed, Apr 10, 2013 at 4:27 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com>wrote;wrote:

...

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Every thing has its own flow"

Tudor Girba

11 Apr 11 Apr

9:53 p.m.

Hi, I looked at it a bit. It's a start, but I think the direction is not quite right yet. Let's take a look at one of your examples: builder := ROGridBuilder rows: 3 columns: 1. builder at: 1 at: 1 putModel: #printString shape: shape1. builder at: 2 at: 1 putModel: #instVarNames shape: shape2 innerShape: ROLabel layout: ROVerticalLineLayout new. I like that you are using a matrix model. But, what is not so clean is mixing shapes and elements. Right now, you are creating elements within the definition of the shape (i.e., #instVarNames). A rule of thumb should be that shapes should be interchangeable. Consider the following Mondrian example: | builder | builder := MOFormsBuilder new. builder column; pref; center; row; fill; row; fill. builder x:1 y:1 add: (MORectangleShape new text: #asString; withoutBorder). builder x:1 y:2 add: MOChildrenShape new. view shape: builder asShape. view node: 42 forIt: [ view nodes: (1 to: 42). view gridLayout ] In this case, I can keep the graph structure the same and simply use another shape, and it still works (In this case, the rectangle has a default way of handling children elements). view node: 42 forIt: [ view nodes: (1 to: 42). view gridLayout ] I am not suggesting that FormsBuilder is the ultimate design. It's not. However, I still think it's good to keep a shape be a way of specifying how elements look, not how elements are composed. The way we achieved this was through ChildrenShape, which simply offers a placeholder for where the children elements are rendered. The limitation of the previous design was that we only allowed one ChildrenShape. This is why we either showed methods or attributes in the uml class diagram. But I think we could remedy the situation by having some sort of partitioning of the children. For example, we could tag children and then associate the tags to the different ChildrenShapes. Ok, that is it for the moment. Doru On Apr 10, 2013, at 4:30 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:

...

Thanks! Now, it will be easier to review :) Doru On Wed, Apr 10, 2013 at 4:27 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: Hi Doru, thank you for the navigation. There is the script: Gofer new smalltalkhubUser: 'JurajKubelka' project: 'RoassalProposals'; package: 'Roassal'; load. ROGridBuilderTest browse. Cheers, Jura 2013/4/10 Tudor Girba <tudor(a)tudorgirba.com> Hi Juraj, Great to see this starting. To make collaboration easier please do the following: - create a separate repository on SmalltalkHub - put your Roassal extensions there - send a Gofer script to load this code easily in a Moose image. (ask specific questions if you do not find out how to do it) In the meantime, I will try like it is now. Cheers, Doru On Wed, Apr 10, 2013 at 4:03 AM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: Hi all, Hi Doru! There is the kick-off of ComplexShape implementation in Roassal. If you file-in the attached code into https://ci.inria.fr/moose/job/moose-latest-dev-4.8/, you will be able to play with it a bit. There is ROGridBuilderTest test class with two examples. Doru, I suppose you are almost only one who manage Mondrian's complex shapes. Would you please examine the code and give me your opinion? Thank you a lot. … Of course any one can give me some feedback :-) I would appreciate it. For now I focused to do UML Class diagram. I know about blue-prints which can be done similar way. I have not seen other complex shapes. So there is an open space for other requirements which can impact interface and design. Implementation breaks several tests because of change in ROContainer>>encompassingNestedRectangle. I removed a default extent (5@5) which is not wanted. I will fix the tests later when the implementation will be accepted. Thank you for any response or question, Jura <roassal-complexshape-export-of-roshape.png> _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow"

-- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Alexandre Bergel

12 Apr 12 Apr

12:13 a.m.

Hi Doru! Thanks for having a look at Juraj's work.

...

A rule of thumb should be that shapes should be interchangeable. Consider the following Mondrian

One of the main hypothesis of Juraj's work, I have the impression, is that there is only one way to compose graphical widget, which is given by nesting ROElements. The GridBuilder is about efficiently building grid, whereas MondrianBuilder is about efficiently build possibility nested graphs. So far, I see that the GridBuilder should be a compelling mini language to build DSM, UML diagrams, Class Blueprint. We have chosen the notation "view nodes: ... using: abuilder". Maybe the using: lexeme is not the best, since we mean grid builder here, and not shapes (as it was in Mondrian).

...

example: | builder | builder := MOFormsBuilder new. builder column; pref; center; row; fill; row; fill. builder x:1 y:1 add: (MORectangleShape new text: #asString; withoutBorder). builder x:1 y:2 add: MOChildrenShape new. view shape: builder asShape. view node: 42 forIt: [ view nodes: (1 to: 42). view gridLayout ] In this case, I can keep the graph structure the same and simply use another shape, and it still works (In this case, the rectangle has a default way of handling children elements). view node: 42 forIt: [ view nodes: (1 to: 42). view gridLayout ]

Something that has always bothered me, is that it is not clear when the MOFormsBuilder is the appropriate construction to use. Consider the Jannik's DSM. How to visually represent it? By having a super-complex shape to which we do a " view node: myDsm" ? Or do you need an appropriate way to build the matrix? You gave a nice use of the FormsBuilder. It makes me realize that it is useful to keep shapes and the structure separate. But why only shapes? And not layout or interactions?

...

I still think it's good to keep a shape be a way of specifying how elements look, not how elements are composed.

Yes. I agree! I am realizing my ideas here are not well ordered. Defining and understand what is the scope of shapes, interaction and elements is tough. Alexandre

...

The way we achieved this was through ChildrenShape, which simply offers a placeholder for where the children elements are rendered. The limitation of the previous design was that we only allowed one ChildrenShape. This is why we either showed methods or attributes in the uml class diagram. But I think we could remedy the situation by having some sort of partitioning of the children. For example, we could tag children and then associate the tags to the different ChildrenShapes. Ok, that is it for the moment. Doru On Apr 10, 2013, at 4:30 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:

-- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Juraj Kubelka

1:22 a.m.

Thank you Doru and Alex! Yes this is a really just start, because I am aware of different direction. I used "element composed strategy" as I have seen for the context menu. I have seen just two examples of complex shapes. One is the UML class, another one blueprint. In general, both of them use shape in order to split the area of element into particular parts (for UML: name, instVars, selectors). I think any UI is build that way: it means it is composed of widgets. Ok, let's say I can understand that complex shape just defines areas inside of elements, his border, colour, maybe resize strategy. Can you please give me an idea, an example of interface which allows two placeholders (ChildrenShape)? I do not mean the definition of builder, but after that. Something like that?: view at: #placeholder1 node: 42 forIt: [ view nodes: (1 to: 42). view gridLayout ]. view at: #placeholder2 node: 42 forIt: [ view nodes: (1 to: 42). view gridLayout ]. And I would appreciate the real example of using it. I have seen just UML class and Blueprint usage. And my impression is to use the "composition strategy" with some nice builder interface. I would actually likely use Spec library. But for now we want something simple and independent of any other library. Thank you for any advice, Jura 2013/4/11 Tudor Girba <tudor(a)tudorgirba.com>

...

Thanks! Now, it will be easier to review :) Doru On Wed, Apr 10, 2013 at 4:27 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com>

wrote:

Hi Doru, thank you for the navigation. There is the script: Gofer new smalltalkhubUser: 'JurajKubelka' project: 'RoassalProposals'; package: 'Roassal'; load. ROGridBuilderTest browse. Cheers, Jura 2013/4/10 Tudor Girba <tudor(a)tudorgirba.com> Hi Juraj, Great to see this starting. To make collaboration easier please do the following: - create a separate repository on SmalltalkHub - put your Roassal extensions there - send a Gofer script to load this code easily in a Moose image. (ask specific questions if you do not find out how to do it) In the meantime, I will try like it is now. Cheers, Doru On Wed, Apr 10, 2013 at 4:03 AM, Juraj Kubelka <juraj.kubelka(a)gmail.com>

wrote:

Hi all, Hi Doru! There is the kick-off of ComplexShape implementation in Roassal. If you

file-in the attached code into https://ci.inria.fr/moose/job/moose-latest-dev-4.8/, you will be able to play with it a bit. There is ROGridBuilderTest test class with two examples.

Doru, I suppose you are almost only one who manage Mondrian's complex

shapes. Would you please examine the code and give me your opinion? Thank you a lot. … Of course any one can give me some feedback :-) I would appreciate it.

For now I focused to do UML Class diagram. I know about blue-prints

which can be done similar way. I have not seen other complex shapes. So there is an open space for other requirements which can impact interface and design.

Implementation breaks several tests because of change in

ROContainer>>encompassingNestedRectangle. I removed a default extent (5@5) which is not wanted. I will fix the tests later when the implementation will be accepted.

Thank you for any response or question, Jura <roassal-complexshape-export-of-roshape.png> _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow"

stephane ducasse

13 Apr 13 Apr

8:50 a.m.

Juraj publish your code on a project, and provide a gofer script. loading st files is not fun at all. Stef On Apr 10, 2013, at 4:03 AM, Juraj Kubelka <Juraj.Kubelka(a)gmail.com> wrote:

...

Juraj Kubelka

2:43 p.m.

...

Juraj publish your code on a project, and provide a gofer script. loading st files is not fun at all. Stef On Apr 10, 2013, at 4:03 AM, Juraj Kubelka <Juraj.Kubelka(a)gmail.com> wrote: Hi all, Hi Doru! There is the kick-off of ComplexShape implementation in Roassal. If you file-in the attached code into https://ci.inria.fr/moose/job/moose-latest-dev-4.8/, you will be able to play with it a bit. There is ROGridBuilderTest test class with two examples. Doru, I suppose you are almost only one who manage Mondrian's complex shapes. Would you please examine the code and give me your opinion? Thank you a lot. … Of course any one can give me some feedback :-) I would appreciate it. For now I focused to do UML Class diagram. I know about blue-prints which can be done similar way. I have not seen other complex shapes. So there is an open space for other requirements which can impact interface and design. Implementation breaks several tests because of change in ROContainer>>encompassingNestedRectangle. I removed a default extent (5@5) which is not wanted. I will fix the tests later when the implementation will be accepted. Thank you for any response or question, Jura <roassal-complexshape-export-of-roshape.png> <Roassal-ComplexShape-Tests.st><Roassal-ComplexShape.st> <ROContainer-encompassingNestedRectangle.st><ROGridLayout class-onwithGapwithLineItemsCount.st><ROMondrianViewBuilder-nodesusing.st> <ROMondrianViewBuilder-nodeusing.st><ROShape class-chainedCopy.st> _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

stephane ducasse

8:20 p.m.

thanks! You can read the gofer chapter that we wrote. Stef On Apr 13, 2013, at 2:43 PM, Juraj Kubelka <Juraj.Kubelka(a)gmail.com> wrote:

...

Hi Stef, Thank you, Doru already teached me about it. Here it is: Gofer new smalltalkhubUser: 'JurajKubelka' project: 'RoassalProposals'; package: 'Roassal'; load. ROGridBuilderTest browse. Cheers, Jura 2013/4/13 stephane ducasse <stephane.ducasse(a)free.fr> Juraj publish your code on a project, and provide a gofer script. loading st files is not fun at all. Stef On Apr 10, 2013, at 4:03 AM, Juraj Kubelka <Juraj.Kubelka(a)gmail.com> wrote:

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

4271

days inactive

4274

days old

moose-dev@list.inf.unibe.ch

Manage subscription

9 comments

4 participants

tags (0)

participants (4)

Alexandre Bergel
Juraj Kubelka
stephane ducasse
Tudor Girba