Diff for "Outdated_Cytoscape_3.0/Mini_Retreat2"

Need a concept of how to link/join tables to networks and how these are synchronized (e.g. how selection state is synchronized - do we need a CyTable that can't be unlinked from a CyNetwork that stores e.g. selection state and then enable developers to link additional data tables as local tables for that network? This would set up a one to many relationship between networks and tables) - added Oct.2010

CyTable views - added Oct.2010

• we should have a code test writing jamboree - write tests to capture specific behavior
  • could be opened up to the plugin writing community, like we did in the past with 'day of bug testing' with people distributed and asking questions on IRC

• Develop a unified settings/preferences system that supports global and session specific settings/properties. Also, make available as an API for plugin developers.
  • Implement a clear global vs. session separation for properties - they are not well distinguished in 2.x (e.g. proxy settings are stored in the session file)
  • This would allow the session IO system to access global properties, which it currently can't do, so is forced to take these from the current active set (which can be changed by the user). Thus, when you create a new session, you may save some global and edited properties that don't make sense to save in the session.
• Unify bookmarks and linkout systems - currently we have both, but we should have one. Need to support editing of linkouts, setting in configuration files - may be easily made part of a general system for settings
• Create a cytoscape 3.0 session format?
  • Better format for serializing visual styles - not just properties. E.g. XML
  • Re-evaluate XGMML?

    • Should we have separate XML serializable objects for CyTable vs. CyNetwork? Other objects that are stored in XGMML? Would be more flexible and modular.

    • XGMML is not maintained, was always a draft standard.
    • Cytoscape stores all visual and data properties as attributes and doesn't make use of the XGMML graphics system for storing node/edge graphics.
    • IDs are very messy with XGMML, because it requires IDs to be numbers, not strings, while Cytoscape uses strings, so Cytoscape is forced to store its unique IDs in the label field, which is not unique in XGMML.

• In 2.8 we create a fake visual style that is inferred from the graphics information in the file. This is useful because in 2.8 the visual style gets applied every time a network gets redrawn. If we were to set the visual properties directory in a network view, they would be lost almost immediately because we redraw networks so often. However, creating the fake visual style along with fake attributes presents UI issues and makes the parser code more complicated.
• In 3.0 we have a locking mechanism for visual properties in a network view, so we could set those values from the graphics information in the file and then lock them. However, as things currently stand, the only UI mechanism for unlocking these values are the bypass menus. This means we'd need a new UI element (button, menu item, whatever) that removes these locked values.
• If we use the locking mechanism, then unlock the visual properties and change them with a visual style, we'll loose the original visual properties. Is this OK?