RFC Name : Visual Style Simplification |
Editor(s): MikeSmoot |
Date: 10/29/07 |
Status: open |
<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>
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:
- 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.
The mapping object should be added directly to the VisualStyle object, which means we can bypass the NodeAppearanceCalculator nonsense.
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
Issues
This will break many, many things.
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.