Porting DSM to Roassal?
Locked
 
|
Hi!
I've spent a bit of time in trying to port DSM to Roassal. Unfortunately not everything goes as smooth as I wished. The task is clearly doable, but it is a bit more than merely changing MOViewRenderer for ROMondrianViewBuilder. For example, there is code like: shapeOfDetailedHeader ^ MOFixedRectangleShape new width: 36; height: 10; withoutBorder; fontSize: 8; fontFamily: 'Accuny' In Roassal, the width and the height is defined on the element, and not the shape. A ROBox does not know how to display text, it has to be added a ROLabel in it. Well... I feel the safer is to revert what I have done yesterday, and leaving DSM use Mondrian. Else if someone wants to rethink DSM a bit. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Alex,
On 23 May 2012, at 00:57, Alexandre Bergel wrote: > Hi! > > I've spent a bit of time in trying to port DSM to Roassal. Unfortunately not everything goes as smooth as I wished. The task is clearly doable, but it is a bit more than merely changing MOViewRenderer for ROMondrianViewBuilder. > For example, there is code like: > shapeOfDetailedHeader > ^ MOFixedRectangleShape new width: 36; height: 10; withoutBorder; fontSize: 8; fontFamily: 'Accuny' > > In Roassal, the width and the height is defined on the element, and not the shape. A ROBox does not know how to display text, it has to be added a ROLabel in it. I think you are mistaken the width of a shape with the bounds of an element. For example, if you have a complex shape, you will have shapes with different widths within the same bounds of the overall element. So, it should still be the responsibility of a shape to decide the visual width, and the responsibility of the element is to decide the spatial width. On a related note, I mentioned before that even if you have decorators, you are still missing the possibility of the decorator to enlarge the bounds. Cheers, Doru > Well... I feel the safer is to revert what I have done yesterday, and leaving DSM use Mondrian. Else if someone wants to rethink DSM a bit. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Value is always contextual." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Well... I did this because in Mondrian it was a complete mess with the width and height defined on a shape that has to be cached in a node. At the top of this, I then realized that a node may have several shapes using the complex form. This resulted in a complex piece of code.
Having the bounds defined on a shape is indeed a possibility that I may explore. Before adding new things on the API I would like to have case studies. I will port some of the mondrian scripts. Thanks for triggering this discussion. Cheers, Alexandre Le 23 mai 2012 à 03:24, Tudor Girba <[hidden email]> a écrit : > Hi Alex, > > On 23 May 2012, at 00:57, Alexandre Bergel wrote: > >> Hi! >> >> I've spent a bit of time in trying to port DSM to Roassal. Unfortunately not everything goes as smooth as I wished. The task is clearly doable, but it is a bit more than merely changing MOViewRenderer for ROMondrianViewBuilder. >> For example, there is code like: >> shapeOfDetailedHeader >> ^ MOFixedRectangleShape new width: 36; height: 10; withoutBorder; fontSize: 8; fontFamily: 'Accuny' >> >> In Roassal, the width and the height is defined on the element, and not the shape. A ROBox does not know how to display text, it has to be added a ROLabel in it. > > I think you are mistaken the width of a shape with the bounds of an element. For example, if you have a complex shape, you will have shapes with different widths within the same bounds of the overall element. > > So, it should still be the responsibility of a shape to decide the visual width, and the responsibility of the element is to decide the spatial width. > > On a related note, I mentioned before that even if you have decorators, you are still missing the possibility of the decorator to enlarge the bounds. > > Cheers, > Doru > > >> Well... I feel the safer is to revert what I have done yesterday, and leaving DSM use Mondrian. Else if someone wants to rethink DSM a bit. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Value is always contextual." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Alex,
On 23 May 2012, at 16:17, Alexandre Bergel wrote: > Well... I did this because in Mondrian it was a complete mess with the width and height defined on a shape that has to be cached in a node. At the top of this, I then realized that a node may have several shapes using the complex form. This resulted in a complex piece of code. Actually, it was not that complex: instead of an instance variable in the shape, we had a dictionary in the element. The reason for this was that a shape object was shared among multiple elements. Thus, it had to be stateless, and the real state was stored in the element in a dictionary that had as keys the shape instances. In Roassal, this restriction is not there anymore because you have each element with its shape (essentially this more than doubles the amount of objects generated, which we saw as problematic for large graphs). So, you can just use instance variables. Nevertheless, the key is to understand the distinction between the visual characteristics (like width, height or padding - which belong to the shape), and the spatial dimensions (i.e. the actual bounds - which belong to the element). These are not the same. This becomes apparent when you have composite shapes for an element. In that case, the shape should be allowed to affect the bounds of the element due to its size. Right now, it cannot. > Having the bounds defined on a shape is indeed a possibility that I may explore. We should be more precise with terminology. The bounds are not defined in the shape. They are just affected by the shape. The bounds belong to the element. The element keeps the physical dimensions on the canvas, and the shape is responsible for keeping the information needed for drawing within these bounds. > Before adding new things on the API I would like to have case studies. I will port some of the mondrian scripts. You already have the case study: you already added width in the ROAbstractLine :). Width defines the way the shape is drawn, and it can affect the bounds as well. It should be the same in all other shapes. > Thanks for triggering this discussion. My pleasure. Cheers, Doru > Cheers, > Alexandre > > > > Le 23 mai 2012 à 03:24, Tudor Girba <[hidden email]> a écrit : > >> Hi Alex, >> >> On 23 May 2012, at 00:57, Alexandre Bergel wrote: >> >>> Hi! >>> >>> I've spent a bit of time in trying to port DSM to Roassal. Unfortunately not everything goes as smooth as I wished. The task is clearly doable, but it is a bit more than merely changing MOViewRenderer for ROMondrianViewBuilder. >>> For example, there is code like: >>> shapeOfDetailedHeader >>> ^ MOFixedRectangleShape new width: 36; height: 10; withoutBorder; fontSize: 8; fontFamily: 'Accuny' >>> >>> In Roassal, the width and the height is defined on the element, and not the shape. A ROBox does not know how to display text, it has to be added a ROLabel in it. >> >> I think you are mistaken the width of a shape with the bounds of an element. For example, if you have a complex shape, you will have shapes with different widths within the same bounds of the overall element. >> >> So, it should still be the responsibility of a shape to decide the visual width, and the responsibility of the element is to decide the spatial width. >> >> On a related note, I mentioned before that even if you have decorators, you are still missing the possibility of the decorator to enlarge the bounds. >> >> Cheers, >> Doru >> >> >>> Well... I feel the safer is to revert what I have done yesterday, and leaving DSM use Mondrian. Else if someone wants to rethink DSM a bit. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Value is always contextual." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Cool design doru.
I remember thinking about the trick of the typeScanner/TypeScanner to share a large object while being able to customize it on a per instance level. Indeed sharing shape when possible is nice. Stef On May 23, 2012, at 9:37 PM, Tudor Girba wrote: > Hi Alex, > > On 23 May 2012, at 16:17, Alexandre Bergel wrote: > >> Well... I did this because in Mondrian it was a complete mess with the width and height defined on a shape that has to be cached in a node. At the top of this, I then realized that a node may have several shapes using the complex form. This resulted in a complex piece of code. > > Actually, it was not that complex: instead of an instance variable in the shape, we had a dictionary in the element. The reason for this was that a shape object was shared among multiple elements. Thus, it had to be stateless, and the real state was stored in the element in a dictionary that had as keys the shape instances. > > In Roassal, this restriction is not there anymore because you have each element with its shape (essentially this more than doubles the amount of objects generated, which we saw as problematic for large graphs). So, you can just use instance variables. > > Nevertheless, the key is to understand the distinction between the visual characteristics (like width, height or padding - which belong to the shape), and the spatial dimensions (i.e. the actual bounds - which belong to the element). These are not the same. > > This becomes apparent when you have composite shapes for an element. In that case, the shape should be allowed to affect the bounds of the element due to its size. Right now, it cannot. > >> Having the bounds defined on a shape is indeed a possibility that I may explore. > > We should be more precise with terminology. > > The bounds are not defined in the shape. They are just affected by the shape. The bounds belong to the element. The element keeps the physical dimensions on the canvas, and the shape is responsible for keeping the information needed for drawing within these bounds. > >> Before adding new things on the API I would like to have case studies. I will port some of the mondrian scripts. > > You already have the case study: you already added width in the ROAbstractLine :). Width defines the way the shape is drawn, and it can affect the bounds as well. It should be the same in all other shapes. > >> Thanks for triggering this discussion. > > My pleasure. > > Cheers, > Doru > >> Cheers, >> Alexandre >> >> >> >> Le 23 mai 2012 à 03:24, Tudor Girba <[hidden email]> a écrit : >> >>> Hi Alex, >>> >>> On 23 May 2012, at 00:57, Alexandre Bergel wrote: >>> >>>> Hi! >>>> >>>> I've spent a bit of time in trying to port DSM to Roassal. Unfortunately not everything goes as smooth as I wished. The task is clearly doable, but it is a bit more than merely changing MOViewRenderer for ROMondrianViewBuilder. >>>> For example, there is code like: >>>> shapeOfDetailedHeader >>>> ^ MOFixedRectangleShape new width: 36; height: 10; withoutBorder; fontSize: 8; fontFamily: 'Accuny' >>>> >>>> In Roassal, the width and the height is defined on the element, and not the shape. A ROBox does not know how to display text, it has to be added a ROLabel in it. >>> >>> I think you are mistaken the width of a shape with the bounds of an element. For example, if you have a complex shape, you will have shapes with different widths within the same bounds of the overall element. >>> >>> So, it should still be the responsibility of a shape to decide the visual width, and the responsibility of the element is to decide the spatial width. >>> >>> On a related note, I mentioned before that even if you have decorators, you are still missing the possibility of the decorator to enlarge the bounds. >>> >>> Cheers, >>> Doru >>> >>> >>>> Well... I feel the safer is to revert what I have done yesterday, and leaving DSM use Mondrian. Else if someone wants to rethink DSM a bit. >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Value is always contextual." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |