Hi,
On 12 Dec 2012, at 00:26, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
@Doru: The mondrian DSL in Roassal assigns a copy of
the shape for each element. This is different from what we had in Mondrian. The reason for
copying the shape, is that having a copy makes singular update much much easier, i.e.,
temporarily changing the color of an element.
I know you have a shape per element, but I think the above argument is rather weak :).
Even if you share the shape, you can still just associate a new copy to the element when
you want to modify it.
Yes, indeed. However this adds some extra work to do, and I do not see a nice way to do
it transparently (but I haven't tried very hard, that's true).
Maybe the mondrian builder can do something about that.
Yes, but for that you should not rely on shape copying too deep in the engine.
But, I thought
that the original argument was that if you have a shape per element, you could store
actual values directly in the shape (for example, for caching).
So far, I have no evidence that caching at the level of the shape or the element makes a
significant difference.
I know :). We had this discussion before, and with that occasion I argued that there is no
real reason for the shape to be stateful unless you are composing shapes. Right now, the
composition of shapes does not affect the bounds. As soon as you will compose them, you
will likely feel the need to cache the bounds computation per shape. In Mondrian, we
stored these values in the element (with the shape object as key). The end result was that
Mondrian has half the amount of objects Roassal has for the same view.
Cheers,
Doru
Alexandre
On Dec 6, 2012, at 12:56 PM, Vanessa Peña Araya <van.c.pena(a)gmail.com> wrote:
The problem was that, while constructing the
nodes in the Mondrian builder, the shape assigned to each was a copy of the current shape.
But this was a normal copy that didn't copy the chain of shapes. That means that all
nodes were connected to the current shape and not to a copy. So, for each node you had a
shape like this:
A ROBox -> a ROLabel -> a ROChildrenShape -> a ROChildrenShape -> a
ROChildrenShape -> ... lots of ROChildrenShape ... -> a ROChildrenShape ->
aRONullShape.
So when a node was update, ALL the shapes of the other nodes were updated too.
Vanessa.
On 12/06/2012 05:04 AM, Tudor Girba wrote:
> What was the problem?
>
> Doru
>
>
> On Wed, Dec 5, 2012 at 7:22 PM, Vanessa Peña Araya <van.c.pena(a)gmail.com>
wrote:
> Hi Roberto,
>
> I checked and yes, there was a little ugly bug :P I commited a new version, can you
try and see if it works now, please?
>
> Vanessa.
>
>
> On 12/05/2012 11:20 AM, roberto.minelli(a)usi.ch wrote:
> Hi guys,
>
> I'm using Roassal to build a visualization that looks like the following:
>
>
http://www.xconomy.com/wordpress/wp-content/images/2012/11/skeuo-calendar.p…
>
> I create two ad-hoc layouts (i.e., extending the ROGridLayout) to individually layout
days inside months and months inside years.
>
> I have a piece of code that looks something like:
>
> view shape rectangle withText.
>
> view nodes: nodes forEach: [ :aGroupOfObjects | | innerNodes |
>
> innerNodes := do something with aGroupOfObjects.
> ...
> view shape rectangle size: 25; withCenteredText.
> ...
> view nodes: innerNodes.
> view layout: ROMonthLayout new.
> ]
>
> view layout: ROYearLayout new.
>
> view edges: ...
>
> Notice that I want the both the outer node (i.e., the month container) and the inner
nodes (i.e., days) with labels.
>
> The problem is that when I set both nodes with labels the view takes time to be
generated and interactions become impossible (i.e., the whole image actually becomes slow
and you can no longer drag around shapes in the view).
>
> I explored the issue a little bit and discovered that it might be something related
to ROShape>>chainedDrawOn:for: and the way Roassal handles shapes with
"nested" shapes (i.e., when 'next' is not a RONullShape .
>
> I inspected one of my outer nodes and discovered that I have a chain such that
'outerNode next' is a ROLabel and the ROLabel has a ROChildrenShape as next and
the next of the ROChildrenShape is a RONullShape .
>
> Have you ever experienced such a problem? Do you know how can I handle that? Do you
see any potential problem in the snippet I posted above?
>
> Cheers and thanks in advance,
> Roberto
> _______________________________________________
> 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"
>
>
>
> _______________________________________________
> 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
"The coherence of a trip is given by the clearness of the goal."
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Innovation comes in the least expected form.
That is, if it is expected, it already happened."