Issue 888 in moose-technology: MondrianViewBuilder should support a better zOrder

Status: New
Owner: ----
CC: [hidden email]
Labels: Type-Enhancement Priority-Medium Component-Roassal

New issue 888 by [hidden email]: MondrianViewBuilder should support a  
better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

Here is a little example:
view shape label text: #yourself.
view nodes: (1 to: 20).
view edges: (1 to: 20) from: [:x | x // 2] to: 1.
view edges: (1 to: 20) from: [:x | x // 3] to: 2.
view edges: (1 to: 20) from: [:x | x // 5] to: #yourself.
view edges: (1 to: 20) from: [:x | x // 7] to: #yourself.
view dominanceTreeLayout

Open this one is Mondrian and then in the Roassal Easel.

Then, try to select 1.

In Roassal, you cannot select 1 because of the edges that go on top of it.  
What is more, you also can barely see it. This situation will always appear  
in graphs with edges that cross the nodes.

Given that at least the MondrianViewBuilder should be about mapping domain  
models onto graphs, having a sensible zOrder, at least in the  
MondrianViewBuilder is important.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #1 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

The content of the mail sent today:

I agree with you Doru. Two weeks ago I have seen Emmanuel Pietriga (INRIA  
guy) who has designed ZVTM. There is plenty of good ideas in it. One that I  
like is about managing the z-index. In ZVTM, different strategies can be  
plugged to compute the z-index. I took this idea for Roassal.

A view or a any graphical element can now have an instance of ROZOrdering  
that gives a zIndex to each added element. Here is an example:

-=-=-=-=-=-=-=-=-=-=-=-=
view raw zOrdering: (ROZOrdering new
                                                at: 5 put: #isEdge;
                                                at: 10 put: #isNotEdge).
                                               
view shape label text: #yourself.
view nodes: (1 to: 20).
view edges: (1 to: 20) from: [:x | x // 2] to: 1.
view edges: (1 to: 20) from: [:x | x // 3] to: 2.
view edges: (1 to: 20) from: [:x | x // 5] to: #yourself.
view edges: (1 to: 20) from: [:x | x // 7] to: #yourself.
view dominanceTreeLayout.
-=-=-=-=-=-=-=-=-=-=-=-=

ROZOrdering also support dynamically computed zIndex, such as:
-=-=-=-=-=-=-=-=-=
view raw zOrdering: (ROZOrdering new
                                                at: [ :element | element depth ] put: true).
-=-=-=-=-=-=-=-=-=

This means that the zIndex is based on the nesting of the element.  
Currently this does not quite work since the zOrdering is not passed along  
the nesting. For the Mondrian DSL, we need a default ROZOrdering, probably  
based on the nesting depth.

Any comment?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Labels: Milestone-4.7

Comment #2 on issue 888 by [hidden email]: MondrianViewBuilder should  
support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

Great. Having strategies is definitely what I would want as well.

And I am happy that you agreed to add zIndex to the AbstractComponent :).  
This saves a lot of traversing.

Now, about Mondrian:
- every node had
    zOrder := self owner zOrder + 2
We can also make it zOrder := element depth * 2

- every edge had:
    zOrder := (self source zOrder max: self target zOrder) - 1

In other words, the edges took the largest zOrder between the target and  
then decreased it with one to be in between. This works well for highly  
nested graphs. However, this implies that the nodes zOrder is computable  
first. I did not check yet in the implementation.

Anyway, we make it an important issue for 4.7.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #3 on issue 888 by [hidden email]: MondrianViewBuilder should  
support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

I guess we could implement the Mondrian zOrder like this:
view raw zOrdering: (ROZOrdering new
                                                at: [:edge | ((edge source depth * 2) max: (edge target depth * 2)) -  
1 ] put: #isEdge;
                                                at: [ :element | element depth * 2 ] put: #isNotEdge).
                                       
view node: 1 forIt: [view node: 11].
view node: 2 forIt: [view node: 22].
view node: 3 forIt: [view node: 33].
view edgeFromAssociation: 11->33.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #4 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

Something like this yes. I am working on this right now. I will modify the  
builder to have this zordering to all the nodes.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Status: Started

Comment #5 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

Fixed in Roassal 1.213 !
The zOrdering is now per default on all the nodes.

Doru, maybe you have some more sophisticated way to test this. It would be  
cool to have class blueprint using Roassal. This will be a beast that we  
cannot avoid any longer.

Feel free to close it if you are happy with the way it works.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #6 on issue 888 by [hidden email]: MondrianViewBuilder should  
support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

I do not quite understand.

I tried the example:
view raw zOrdering: (ROZOrdering new
                at: [:edge | ((edge source depth * 2) max: (edge target depth * 2)) - 1 ]  
put: #isEdge;
                at: [ :element | element depth * 2 ] put: #isNotEdge).
view node: 1 forIt: [view node: 11].
view node: 2 forIt: [view node: 22].
view node: 3 forIt: [view node: 33].
view edgeFromAssociation: 11->33.

We have the following zIndex:
- nodes 1,2,3: zIndex 2
- nodes 11,22,33: zIndex 4
- edge: zIndex 3

However, the edge still gets drawn on top of node 22. It should be drawn  
below it.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #7 on issue 888 by [hidden email]: MondrianViewBuilder should  
support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

Can we focus on this issue before releasing 4.7?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Yes. Yesterday it was the end of the semester, which is highly time consuming. I have time this week end to work on it.

Cheers,
Alexandre


On Dec 8, 2012, at 10:26 AM, [hidden email] wrote:

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



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #8 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

I thought about how can we address this. I put my thought here to make sure  
my reasoning does not miss anything.

Apparently, the behavior of the zordering implies a deep change in Roassal  
(which should not be that painful however). Currently, the nesting shown in  
the visualization is reflected in the composition of Roassal elements. For  
example, using the previous example, the view contains 4 elements: 1, 2, 3,  
11->33. Element 1 contains 11, Element 2 contains 22 and Element 3 contains  
33. The drawing of the view iterates on each elements contains in the view,  
draw recursively each element.
This is the reason why the edge is drawn after nodes 1, 2, 3. The zIndex of  
the edge is 3, and the top level nodes is 2. Since each node draws itself  
and its subelements, nodes 22 is drawn before the edge, independently of  
its zindex. A subelement has a relative position against its parent node  
and the node lookup makes use of the relative position.

To properly address this issue, I think that all the elements should be  
treated independently whether they are nested or not. There should be just  
one collection that contains all the elements to be drawn. All elements  
will have an absolute position.

I have started to work on this... Give me a few days



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #9 on issue 888 by [hidden email]: MondrianViewBuilder should  
support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

Indeed, all elements should be rendered independently of their nesting  
level :).

That is why it is important to have the zIndex in the element, and ideally,  
we should also store the order by level in the ZOrdering.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Status: Fixed

Comment #10 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

Roassal 1.223 fixes this

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #11 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

I just tested it. Very cool.

I have not read the code yet, but I will :)

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #12 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

Started to read the code:

- I like it that the sorting happens in place in ROView. I just think I  
would have put it in ZOrdering, though.

- What is the reason for not allowing the changing of zOrdering if elements  
already exist?
zOrdering: aZOrdering
        elementsToRender notEmpty ifTrue: [ self error: 'Cannot change the  
zOrdering if elements are present' ].
        elementsToRender := SortedCollection sortBlock: [ :a :b | a zIndex < b  
zIndex ].
        zOrdering := aZOrdering

I see no reason why we could not apply the sorting to existing elements if  
wanted.

- I think ZOrdering>>at: integerOrValue put: aBlockOrAValue is confusing. I  
would give it a more explicit name.

- The default ZOrdering from ROMondrianViewBuilder is good now. It makes a  
big difference.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #13 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

- What is the reason for not allowing the changing of zOrdering if elements  
already exist?
...
I see no reason why we could not apply the sorting to existing elements if  
wanted.


Thanks Doru for raising this point!
I removed this constraint in 1.227

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #14 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

- I like it that the sorting happens in place in ROView. I just think I  
would have put it in ZOrdering, though.

I agree with you, however I would need to provide a direct accessor to  
elementsToRender, and I would rather avoid this.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Status: Started

Comment #15 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

- I think ZOrdering>>at: integerOrValue put: aBlockOrAValue is confusing. I  
would give it a more explicit name.

What about #giveZIndex:if: ?
Anything better?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #16 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

zIndex:for: ?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #17 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

I like to have method name as a verb :-)

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Status: Fixed

Comment #18 on issue 888 by [hidden email]: MondrianViewBuilder  
should support a better zOrder
http://code.google.com/p/moose-technology/issues/detail?id=888

This is fixed I believe.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev