## page was renamed from RFC Template ## This template should be used for creating new RFC's (Request for comments) for Cytoscape development || '''RFC Name''' : Visual Style Simplification|| '''Editor(s)''': MikeSmoot || '''Date''': 10/29/07 ||'''Status''': open || <> == Proposal == Simplify the process of creating and applying VisualStyles in Cytoscape for plugin writers and the core. === Background === Creating and applying !VisualStyles in Cytoscape is currently very cumbersome. Recent improvements to the !VizMapper code have simplified some things, but others remain. The primary difficulty in creating visual styles is the many layers of objects that need to be created for !VisualStyles to work. Users need to create or get the following: * A mapping for the attribute in question. * A Calculator for the particular visual attribute and mapping. * The !NodeAppearanceCalculator. * The !EdgeAppearanceCalculator. * The !GlobalAppearanceCalculator. * The !VisualStyle. * The !VisualMappingManager. * Possibly the calculator catalog. Applying visual styles is also complicated, because there are apparently different ways to do this. There is a setVisualStyle method on !CyNetworkView and there is one in !VisualMappingManager. Which should be used? Should you use !CyNetworkView.applyVizMapper() or !VisualMappingManager.applyAppearance()? == Use Cases == A plugin writer wants to associate a data attribute with a visual attribute. == Implementation Plan == The should be relatively straightforward as all of the necessary code exists, it's just distributed in different places. I envision a limited number of interfaces that users will interact with: 1. A Mapping object that also identifies the visual attribute that should be set. This means that the Calculator stuff can go away, or at least be hidden. 1. The mapping object should be added directly to the VisualStyle object, which means we can bypass the NodeAppearanceCalculator nonsense. 1. Simplify application of the visual style to one place, either CyNetworkView or VisualMappingManager. Other considerations: * Simplify the VisualStyle and Mapping interfaces so that the can be easily implemented by plugin writers. * Simplify event handling and where/when visual styles are applied. == Project Management == This will break interfaces, so this is 3.0 thing. === Project Timeline === All of the code exists, it just needs to be reshuffled. This could probably be accomplished in about 1 month's time. === Project Dependencies === Anything that depends on the VizMapper, which is to say everything, will probably break to one degree or another. This is not a change to make lightly. Best done along with everything else for 3.0. == Related RFCs == * CytoscapeLayerRefactor * EventHandling == Issues == This will break many, many things. == 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.'''