Diff for "TooltipsAndContextMenusForRender"

Differences between revisions 11 and 12

RFC Name : ...

Editor(s): ...

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 [http://www.answers.com/main/ntquery?method=4&dsid=2222&dekey=Request+for+Comments&gwp=8&curtab=2222_1&linktext=Request%20for%20Comments 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().addNodeContextMenuListener(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 is responsible for checking whether the JMenuItem already exists on the menu and doing other sanity checks. I am considering whether some global management of the JPopupMenu should be done in the InnerCanvas routine that instantiates and shows the menu, but I'm not sure if that makes sense.

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

Tooltips

It appears possible to add 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. I 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.

Biological Questions / Use Cases

General Notes

For testing purposes, an experimental version of the renderer's view package, ding.view, can be obtained in the attachment attachment:ding.jar Place this ding.jar file in the cytoscape/lib directory and rebuild cytoscape.

An experimental version of the CytoscapeEditor, which contains context menu items and has been updated to drag and drop Nodes and Edges to the ding InnerCanvas, can be obtained in the attachment attachment:CytoscapeEditor.jar Place the CytoscapeEditor.jar file in the cytoscape/plugins/core directory.

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

Expected growth and plan for growth

References

Implementation Plan

["/Implementation Plan"]

Comments

PageComment2

-  ← Revision 11 as of 2006-05-20 00:30:25 →
  Size: 5642
  Editor: cosiapat1
  Comment:
+  ← Revision 12 as of 2006-05-20 00:35:37 →
  Size: 5665
  Editor: cosiapat1
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 40:
-The CyNetwork interface implements these listener interfaces, so when you have a class that implements these interfaces, you add it to the current network view, e.g.
+The Cy''''''Network 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.
 Line 42:
-  {{{(Cytoscape.getCurrentNetworkView().addNodeContextMenuListener(this);}}}
+  {{{Cytoscape.getCurrentNetworkView().addNodeContextMenuListener(this);}}}

  {{{Cytoscape.getCurrentNetworkView().addNodeContextMenuListener(this);}}}
-Line 44:
+Line 45:
-I am thinking about whether this should be pushed up to the Cy''''''Network level to eliminate the need for typecasting, but initially I couldn't get this to work without moving the associated mouse handling code up to the Cytoscape level, where I don't think it should be.  In any event, I think we can worry about this detail later.
+The routines for building the context menus are in the Inner''''''Canvas class.  Basic idea is that the Inner''''''Canvas instantiates the popup menu, then, depending upon whether a Node''''''View or Edge''''''View is the object right-clicked upon, calls the addNodeContextMenuItems() method on each Node''''''Context''''''Menu''''''Listener or the addEdgeContextMenuItems() method on each Edge''''''Context''''''Menu''''''Listener , then shows the menu.
-Line 46:
+Line 47:
-The routine for building the context menu is in the Inner''''''Canvas class.  Basic idea is that the Inner''''''Canvas instantiates the popup menu, calls the addNodeContextMenuItems() method on each Node''''''Context''''''Menu''''''Listener, then shows the menu.  



Each Node''''''Context''''''Menu''''''Listener can add J''''''Menu''''''Items, separators, basically do whatever it wants with the J''''''Popup''''''Menu that is passed in to it, all of this using the conventional swing methods for building up menu items.    Under the current scheme, each Node''''''Context''''''Menu''''''Listener is responsible for checking whether the JMenuItem already exists on the menu and doing other sanity checks.  I am considering whether some global management of the J''''''Popup''''''Menu should be done in the Inner''''''Canvas routine that instantiates and shows the menu, but I'm not sure if that makes sense.
+Each Node''''''Context''''''Menu''''''Listener and Edge''''''Context''''''Menu''''''Listener can add J''''''Menu''''''Items, separators, basically do whatever it wants with the J''''''Popup''''''Menu that is passed in to it, all of this using the conventional swing methods for building up menu items.    Under the current scheme, each Node''''''Context''''''Menu''''''Listener is responsible for checking whether the JMenuItem already exists on the menu and doing other sanity checks.  I am considering whether some global management of the J''''''Popup''''''Menu should be done in the Inner''''''Canvas routine that instantiates and shows the menu, but I'm not sure if that makes sense.