TooltipsAndContextMenusForRender

<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>

About this document

This is an official Request for Comment (RFC) for adding tooltip and context menu functionality to the Cytoscape 2.3 renderer.

For details on RFCs in general, check out the Wikipedia Entry: Request for Comments (RFCs)

Status

revised 19 May 2006 (Allan Kuchinsky)

How to Comment

To view/add comments, click on any of 'Comment' links below. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Here is an example to get things started: /Comment.

Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.

Proposal

Context Menus

Cytoscape 2.3 will feature a redesigned scheme for context menus which are designed to work with the new renderer.

The scheme is based upon two new interfaces called NodeContextMenuListener and EdgeContextMenuListener, each of which has one method for adding menu items to a context menu:

• void addNodeContextMenuItems (NodeView nodeView, JPopupMenu menu);

  void addEdgeContextMenuItems (EdgeView edgeView, JPopupMenu menu);

The CyNetwork interface defines methods for adding node and edge context listeners, so when you have a class that implements these interfaces, you add objects of that class to the current network view, e.g.

• Cytoscape.getCurrentNetworkView().addNodeContextMenuListener(this);

  Cytoscape.getCurrentNetworkView().addEdgeContextMenuListener(this);

The routines for building the context menus are in the InnerCanvas class. Basic idea is that the InnerCanvas instantiates the popup menu, then, depending upon whether a NodeView or EdgeView is the object right-clicked upon, calls the addNodeContextMenuItems() method on each NodeContextMenuListener or the addEdgeContextMenuItems() method on each EdgeContextMenuListener , then shows the menu.

Each NodeContextMenuListener and EdgeContextMenuListener can add JMenuItems, separators, basically do whatever it wants with the JPopupMenu that is passed in to it, all of this using the conventional swing methods for building up menu items. Under the current scheme, each NodeContextMenuListener and EdgeContextMenuListener is responsible for checking whether the JMenuItem already exists on the menu and doing other sanity checks.

This is a more direct and simpler scheme than what has been done for context menus under Cytoscape 2.2.

Tooltips

We have been able to add NodeView tooltip functionality to the renderer without requiring any changes to plugins and other code that uses tooltips.

The renderer's InnerCanvas class is a JComponent, thus one can setToolTipText() on it. We modified the DNodeView class -- not a JComponent -- to maintain an instance variable that is set whenever a call to setToolTip() is made, e.g. when the literature search calls NodeView.setToolTip(). Then, when the mouse hovers over a node on the canvas, the canvas does a call to DNodeView.getToolTip() for that node, then does a setToolTipText() on itself using the text retrieved from the DNodeView.

For performance reasons, tooltips on EdgeViews are not implemented in Cytoscape 2.3.

Biological Questions / Use Cases

General Notes

Requirements

Deferred Items

Open Issues

Are we supposed to use the m_spacial index in DGraphView to figure out which node(s) have been clicked on? Is that the right approach?

How do we figure out what edges have been clicked on?

What's with all of the bitwise complements? Why are these necessary?

What is the reason for the star shaped polygon requirement?

Backward Compatibility

The changes to context menu handling are not backward compatible with earlier versions of Cytoscape. There is no migration path for the previous context menu handling methods, which were tightly coupled to Piccolo.

We should give plugin writers ample time to accommodate these changes and test their plugins.

Expected growth and plan for growth

References

Implementation Plan

• /Implementation Plan

Comments

mskresolve-b - 2006-05-01 09:33:15

The interface has one method:

void addNodeContextMenuItems (Point pt, Object nodeView, JPopupMenu menu);

1. What does Point pt do? I assume that a user who right clicks on a node or edge will trigger addNodeContextMenuItems, and will pass the Point at which the user made the click. However, what is this useful for? Do we really need it? 2. The second parameter is an Object, which is potentially confusing to people, as it is so generic. I assume that's so you can pass nodes or edges? Will there be two interfaces defined, e.g. Node**Context**Menu**Listener and EdgeContextMenuListener? in that case, perhaps we could just make the second parameter a NodeView or EdgeView. 3. I vote to add the context menu listener methods to CyNetwork directly. That way, most plugins don't actually have to be aware of ding.

Ethan

GaryBader - 2006-05-01 11:59:48

What is the reason for the star shaped polygon requirement?  As far as I know, this was an optimization to allow faster drawing.  It would be nice if the nodes could be decorated with user defined shapes (defined by a custom drawing method definted using Java2D) e.g. to represent phosphorylations as little circles attached to the main node shape at a specific location.  I'm not sure if this was ever implemented.  Are you thinking to use that type of thing for a tooltip?

AllanKuchinsky - 2006-05-11 05:25:13

My answers to Ethan's comments interleaved below:

The interface has one method:

void addNodeContextMenuItems (Point pt, Object nodeView, JPopupMenu menu);

1. What does Point pt do? I assume that a user who right clicks on a node or edge will trigger addNodeContextMenuItems, and will pass the Point at which the user made the click. However, what is this useful for? Do we really need it? AJK: Right now my code doesn't use it.  I had originally thought that perhaps some listeners might want to get the position of the node in terms of the canvas coordinate system, but I haven't needed this.  

2. The second parameter is an Object, which is potentially confusing to people, as it is so generic. I assume that's so you can pass nodes or edges? Will there be two interfaces defined, e.g. Node**Context**Menu**Listener and EdgeContextMenuListener? in that case, perhaps we could just make the second parameter a NodeView or EdgeView. AJK: I have been going back and forth between whether to have specific listeners for nodes and edges or whether to have one listener that takes a general object which could be a node or an edge.  If we did the latter, then we'd need to pass in the second parameter as an Object and the user would have to check the type of the argument.  If we do two specific listeners, then we should have the second argument be either a node or an edge.  Do you have a sense of whether the specific or general approach is more intuitive for users/developers?

3. I vote to add the context menu listener methods to CyNetwork directly. That way, most plugins don't actually have to be aware of ding. Yes, I agree.  

AllanKuchinsky - 2006-05-11 05:27:24

and ethan's comments on my comments:

Ideally, Cytoscape would have a GraphObject which is a super class of Node and Edge, and you could have a single GraphObjectContextMenu item interface.  Since, we don't, I vote for two interfaces:  one for nodes and one for edges.

AllanKuchinsky - 2006-05-11 05:27:56

... and Mike's comments on Ethan's comments:

both CyEdge and CyNode implement the giny.model.GraphObject interface.  So if the context menu code only needs to know the node/edge id, then we could have one method using GraphObject.  If the context menu code needs to do something with those nodes and edges, then that might not work because the interface is pretty lean.