Status: New Owner: ---- CC: alexandr...@gmail.com Labels: Type-Enhancement Priority-Medium Component-Roassal
New issue 888 by tu...@tudorgirba.com: 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.
Comment #1 on issue 888 by alexandr...@gmail.com: 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?
Updates: Labels: Milestone-4.7
Comment #2 on issue 888 by tu...@tudorgirba.com: 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.
Comment #3 on issue 888 by tu...@tudorgirba.com: 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.
Comment #4 on issue 888 by alexandr...@gmail.com: 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.
Updates: Status: Started
Comment #5 on issue 888 by alexandr...@gmail.com: 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.
Comment #6 on issue 888 by tu...@tudorgirba.com: 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.
Comment #7 on issue 888 by tu...@tudorgirba.com: 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?
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, moose-technology@googlecode.com wrote:
Comment #7 on issue 888 by tu...@tudorgirba.com: 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Comment #8 on issue 888 by alexandr...@gmail.com: 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
Comment #9 on issue 888 by tu...@tudorgirba.com: 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.
Updates: Status: Fixed
Comment #10 on issue 888 by alexandr...@gmail.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888
Roassal 1.223 fixes this
Comment #11 on issue 888 by tu...@tudorgirba.com: 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 :)
Comment #12 on issue 888 by tu...@tudorgirba.com: 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.
Comment #13 on issue 888 by alexandr...@gmail.com: 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
Comment #14 on issue 888 by alexandr...@gmail.com: 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.
Updates: Status: Started
Comment #15 on issue 888 by alexandr...@gmail.com: 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?
Comment #16 on issue 888 by tu...@tudorgirba.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888
zIndex:for: ?
Comment #17 on issue 888 by alexandr...@gmail.com: 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 :-)
Updates: Status: Fixed
Comment #18 on issue 888 by alexandr...@gmail.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888
This is fixed I believe.
Comment #19 on issue 888 by tu...@tudorgirba.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888
It is!
Updates: Status: New Labels: -Milestone-4.7 Milestone-4.8
Comment #20 on issue 888 by tu...@tudorgirba.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888
This bug just resurfaced: the rendering of the zOrder is broken.
If you do:
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.
You get the correct zOrder: - nodes 1,2,3: zIndex 2 - nodes 11,22,33: zIndex 4 - edge: zIndex 3
But the rendering does not seem to take it into account anymore.
Please let's look at this one. I took a look at the code, but I could not see where the problem is.
Doru
On Sat, Aug 10, 2013 at 11:30 PM, moose-technology@googlecode.com wrote:
Updates: Status: New Labels: -Milestone-4.7 Milestone-4.8
Comment #20 on issue 888 by tu...@tudorgirba.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/**moose-technology/issues/**detail?id=888http://code.google.com/p/moose-technology/issues/detail?id=888
This bug just resurfaced: the rendering of the zOrder is broken.
If you do:
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.
You get the correct zOrder:
- nodes 1,2,3: zIndex 2
- nodes 11,22,33: zIndex 4
- edge: zIndex 3
But the rendering does not seem to take it into account anymore.
-- You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at: https://code.google.com/**hosting/settingshttps://code.google.com/hosting/settings ______________________________**_________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/**mailman/listinfo/moose-devhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
Updates: Labels: -Priority-Medium Priority-High
Comment #21 on issue 888 by alexandr...@gmail.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888
Version 1.405 of roassal fixes this. Quite subtle, related to some caching.
Updates: Status: Fixed
Comment #22 on issue 888 by alexandr...@gmail.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888
(No comment was entered for this change.)
Comment #23 on issue 888 by tu...@tudorgirba.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888
Great. I tested it and it works fine!
Would it maybe possible to add a bitmap-based test to ensure that the rendering does not go wrong on this?
Comment #24 on issue 888 by alexandr...@gmail.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888
testWithEdgesAndNestingWithMondrian tests against a trace of all the graphical primitives invoked. It does not directly tests the bitmap, but using ROTracingCanvas is quite effective.
Comment #25 on issue 888 by tu...@tudorgirba.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888
That is neat!
-
Alexandre Bergel -
moose-technology＠googlecode.com -
Tudor Girba