EventHandling

TableOfContents([2])

Proposal

Organize the event handling in Cytoscape to make it clear and consistent for core developers and plugin developers. As part of the rearchitecting of Cytoscape we can create a coherent event system that will simplify core development, and define the events that plugins can have access to as well as trying to run those events in a manner that prevents plugins from tripping over each other. This will also allow us to fairly easily create a command layer for macros and scripting.

Background

The event handling in the current implementation of Cytoscape has become difficult for even core developers to follow. This means that plugins developers who are interested in doing specific event-driven tasks are in a worse position. This RFC along with the relayering [:CytoscapeLayerRefactor: (46)] address that.

Use Cases

Three main cases (examples, not comprehensive lists):

• Core code event usage
  • Views being created in response to network creation
  • Views modifying in response to network modification

  • VizMapper modifying a node visual in response to attribute creation/modification

• Plugin event usage
  • Adding an option to a popup on a right-click of a node
  • Expanding or navigating subnetwork based on a double-click of a node
  • Creating/applying a particular visual style in response to a network creation
• Command layer
  • macros
  • scripting

Implementation Plan

This plan is a sub-part of the relayering process ([:CytoscapeLayerRefactor: (46) Cytoscape Relayering]). Based on that there are two or three areas for events to be spawned:

1. Model - creation/modification/deletion of a model object such as a network or attribute.
2. Application - actions (used by menus or macros), mouse events, keyboard shortcut events
3. Views - depending on how the view and the application are separated there may be space for events about the creation/modification/deletion of a particular view.

All of these events may be integration points for plugins. At the application and view levels an event queue for plugins would be added. Plugins would register for events and be added to the queue then run in whatever order they were registered. The model layer could also use a queue, but it would be less necessary since these events are not gui related.

Model Events Package Structure

Note, this is the same as proposed in the [:CytoscapeLayerRefactor: relayering] RFC:

http://cytoscape.org/cgi-bin/moin.cgi/CytoscapeLayerRefactor?action=AttachFile&do=get&target=ModelEvents.jpg

Application/View Events Package Structure

This is greatly dependent on how the Application and View packages are separated. However, Views can have an event structure similar to the model (create/modify/select/destroy events) and the Application events will be the basic swing gui events.

Potential integration points for plugins in these packages include:

• Mouse clicks
• Keyboard actions
• Views created/modified/selected/destroyed
• Popup menus on nodes/edges/attributes
• others...

Project Management

Project Timeline

The creation of an event handling system would be part of a re-architecting. As part of the relayering of Cytoscape (RFC 46) the event handling can be restructured during the refactor of packages (Milestone 1). This may add some time (est. 4-6 weeks) to the initial refactor in order to untangle the current event system and add a queue system.

Tasks and Milestones

See the [http://cytoscape.org/cgi-bin/moin.cgi/CytoscapeLayerRefactor#head-063a61e4f10001e3765df5b81b94d12205a21357 Tasks and Milestones] section of [:CytoscapeLayerRefactor: RFC 46].

Project Dependencies

• Plugin rearchitecting - After Milestone 1 in the relayering

Issues

Comments

• Add comment here…

How to Comment

Edit the page and add your comments under the provided header. 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. 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.