Expand-collapse improvements

iVis-at-Bilkent / sbgnviz.js

A web based visualization tool for process description maps in SBGN

http://www.cs.bilkent.edu.tr/~ivis/SBGNViz_sample_app/

GNU Lesser General Public License v3.0

35 stars 14 forks source link

Expand-collapse improvements #48

Closed ugurdogrusoz closed 9 years ago

ugurdogrusoz commented 9 years ago

Collapsed nodes should be resized to be a square with dimensions same as the height of macromolecules (for consistent look).
Collapsed nodes should have their + signs displayed all the time (unlike expanded ones whose - signs should be displayed only when you mouse over). The reason is, otherwise, we have no way of knowing they are actually collapsed.
Collapsed node should have the same label as the compound it corresponds to (displayed in the middle of the node). If the collapsed node is a complex and it doesn't have a label, we should concatenate the labels of all its members (combined with ":" character) to make up a name for the complex (a complex's label with members "a" and "b" should be "a:b"). If it's a compartment, the name of the compartment should be displayed on the collapsed node. We should do these if the collapsed node doesn't already have a label coming from the model.
Meta edges should be a little lighter (more gray).
When you expand or collapse a node, its selection state (selected or not selected) should not change. For instance, currently, when you collapse a node that is not selected, it becomes selected.

metincansiper commented 9 years ago

All orders excluding the latest one are done and the results are reflected to the graph below.

polyq

When a node is collapsed if it has an sbgnlabel it's name is set as the value of this sbgnlabel, if it does not have an sbgnlabel then it's name is determined by it's children's sbgnlabels as described in this issue. However, when a node is getting it's name by the sbgnlabels of it's children, the sbgnlabel of it does not set, just the displaying name of it is set. Therefore, when the mouse cursor is over such a node the name of it, comming from it's children, do not shown as it is shown for the simple node "E3" in the graph above(When mouse cursor is over a node the sbgnlabel of that node is shown if it exists).

Should it remain so, or should the sbgnlabel's are also to be changed when a node is getting it's name from the sbgnlabels of it's children?

ugurdogrusoz commented 9 years ago

How about changing the code for tooltips such that it also does the same thing to come up with a label to display for complexes with no name? This is useful if we decide to shorten complex names in the future since they tend to be long.

ugurdogrusoz commented 9 years ago

Any chance with avoiding selection upon expand-collapse?

metincansiper commented 9 years ago

For the nodes infolabels different from sbgnlabels are defined. Nodes take their infolabel content from their children recursively. When the node is collapsed firstly sbgnlabel of the node is check, if it is null or empty then the infolabel of the node is checked to be set as the content of the collapsed node. The same procedure also works for the qtips.

metincansiper commented 9 years ago

I could not find any way of avoiding selection upon expand-collapse till now. I am searching for a way of doing it.

ugurdogrusoz commented 9 years ago

When do we set infolabels? What if the user changes the label of child node (which is going to be possible as we move SBGNViz into an editor)? Should we not calculate them dynamically on demand / as needed?

ugurdogrusoz commented 9 years ago

Regarding selection, how about deselecting all when expand/collapse is completed?

metincansiper commented 9 years ago

Infolabels are set dynamically on demand. However, I assumed that the children information of a collapsed node could not be changed and also there should be a different function to get the information label of collapsed nodes (because their children are removed and their children data is represented in a different way). Therefore, infolabels for collapsed nodes are calculated when the node is being collapsed and on demand the information label of a collapsed node is not recalculated. If this assumption is not true(e.g. children data of collapsed nodes can be changed) I can handle it in a different way

ugurdogrusoz commented 9 years ago

Let's make sure that we do not keep this label derived from children in memory unless we have to. If this is needed when a node is collapsed, we should remove it upon expand.

metincansiper commented 9 years ago

Expand-collapse operations do not change the selection state of elements anymore.

ugurdogrusoz commented 9 years ago

The only problem I see is that when a selected node/edge is collapsed into a meta node and you deselect (click on the background to reset selection), such nodes/edges (currently not visible) should also be deselected!

metincansiper commented 9 years ago

I think it can be done, however it requires an extra complexity. Because, these currently not visible elements are removed temporarily and we just have the data to restore them when the background is clicked later, so to do such a thing we should listen the background click event and traverse the data of the elements to be restored when the collapsed node is expanded. How about deselecting such elements before the collapse operation?

ugurdogrusoz commented 9 years ago

Sounds good

metincansiper commented 9 years ago

The elements which will be unvisible after collapse operation are unselected before collapse operation is being performed.