23 May
2012
23 May
'12
12:57 a.m.
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
23 May
23 May
9:24 a.m.
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
4:17 p.m.
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 <tudor(a)tudorgirba.com> 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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:37 p.m.
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 <tudor(a)tudorgirba.com> a écrit :
--
www.tudorgirba.com
"Every thing has its own flow."
Hi Alex,
On 23 May 2012, at 00:57, Alexandre Bergel wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
9:56 p.m.
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 <tudor(a)tudorgirba.com> a écrit :
--
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 Hi Alex,
On 23 May 2012, at 00:57, Alexandre Bergel wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4604
days inactive
4605
days old
4 comments
3 participants
participants (3)
-
Alexandre Bergel -
Stéphane Ducasse -
Tudor Girba