## page was renamed from CytoscapeEditor3 ## page was renamed from RFC Template ## This template should be used for creating new RFC's (Request for comments) for Cytoscape development ||'''RFC Name''' : CytoscapeEditor_Palette_3_0 ||'''Editor(s)''': Allan Kuchinsky, Michael Smoot ||'''Date''': 18th January, 2008 ||'''Status''': Under Construction || <> == 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. {{attachment:mims_sample.png}} == 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 Viz''''''Mapper user interface. In particular, the Vizmapper''''''Default''''''Appearance''''''Editor dialog from the Vizmapper's UI could be used as a basis for user configuration of palette entries. The figure below shows the Vizmapper''''''Default''''''Appearance''''''Editor 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. . {{attachment:VizmapperDefaultAppearanceEditor.png}} . 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 -> [[http://www.helpuplan.com/index.asp|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: ... 1. Task 2: ... 1. '''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 == ##If you want to create a separate subpage for Comments, then provide this link: ["/Comment"] * ''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.'''