CytoscapeEditor_Palette_3_0

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

Proposal

• Generalize the mechanism for generating the Cytoscape Editor's palette so that the full range of Cytoscape visual properties is accommodated in the palette

Background

The current Cytoscape mechanism for constructing palettes in the Cytoscape Editor is driven by the current Visual Style. Discrete mappings for Node fill color and shape are used to generate a set of palette entries with varying shapes and colors. Discrete mappings for Edge target arrow are used to generate a set of palette entries with varying target arrow shapes. This limitation is arbitrary and doesn't take advantage of the broad range of Node shapes, colors, size, border characteristics, and other visual properties that can be defined via the vizmapper. Likewise, for edges, the broad range of visual properties available include line width, line style, source arrow. The generation of the palette should be generalized so that any visual property that is defined in the vizmapper can be utilized and reflected in the editing tool.

Use Cases

This enhanced editor functionality would be necessary for editing Molecular Interaction Networks (MiMs). A description of the technical issues related to supporting MiMs in Cytoscape can be found in the RFC MolecularInteractionNetworks. The figure below shows a portion of a molecular interaction network for XXXXX. Note the different shapes, sizes, border characteristics and what they imply for the task of editing such a network interactively.

Implementation Plan

There are two possible approaches under consideration. One would continue the current approach of inferring the palette from the current network and visual style, but would generalize that approach to accommodate all visual properties associated with nodes and edges. This is efficient and expressive, but could result in a cluttered palette if every permutation of the individual visual properties was generated. This presents challenges for ease of use, particularly in cases where only a small number of permutations is needed by the user.

An alternative approach would be to leverage as much as possible from the VizMapper user interface. In particular, the VizmapperDefaultAppearanceEditor dialog from the Vizmapper's UI could be used as a basis for user configuration of palette entries. The figure below shows the VizmapperDefaultAppearanceEditor with settings for node size, shape, color, border characteristics, opacity. In an interface for generating an editor palette, there would probably be additional columns, to the right of the DefaultVisualProperties column, which would list the available node or edge attributes and prompt the user for mappings, where appropriate.

• .

This approach would make the most efficient use of the palette, however it would require more work on the part of the user than would the method of inferring palette from current network and visual style.

Under either approach, when a node or edge is added to the canvas, the attributes and values that underly the visual appearance of the palette entries will be assigned as attribute/value pairs for the nodes and/or edges added.

Persistence for the palette should be accomplished by saving editor state to the Cytoscape session file, via an editor.props file.

Project Management

Project Timeline

Provide a timeline for implementation. Insert a graphic if you can. Try this free online tool for making project timelines -> Help-u-Plan (create a new chart; modify; right-click to save gif; then attach to this page)

Tasks and Milestones

Outline the major milestones and tasks involved in implementation.

1. Milestone 1: …

   1. Task 1: ...
   2. Task 2: ...

2. Milestone 2: …

Project Dependencies

Outline and projects that depend on this project, link to relevant RFC's and note at what point dependent projects could be started.

Related RFCs

Link to other related RFCs

Issues

List any issues, conflict, or dependencies raised by this proposal

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.