Differences between revisions 34 and 35
Revision 34 as of 2008-11-14 14:31:32
Size: 2708
Editor: csik
Comment: resolve trivial conflict
Revision 35 as of 2008-11-14 20:55:31
Size: 5444
Editor: AlexPico
Comment:
Deletions are marked like this. Additions are marked like this.
Line 54: Line 54:
  Review of architecture:
(photo will be attached)

 * UI - Swing, headless
 * Application - will be thin layers with a bunch of Swing code to handle GUI or cmd line input
 * Work -
 * I/O -
 * View Model - State (color), Selection/Highlighting, Hide/Restore, Layout coordinates, supports serialization
 * Presentation -
 * Model -

Examples:
 * Layouts/Tunables - UI is inferred (Swing or cmd line)
 * MCode - can switch to Tunables? Pros and cons.
 * Selection:view - UI selection of graphics with visual feedback
 * Selection:subsets - selection gets passed to model
 * Presentation-based selection - presentation fires selection event, application listens, application tells View Model to define subset (a list that can be serialized), then Presentation layers can respond to subsets

Questions:
 * WIll the plugin dev have to write multiple UIs for each display type (Swing, web, cmd)? Will Tunables suffice for plugins? Or, should we have an abstract UI layer that handles a broader set of UI elements for the diverse front-ends.
 * What exactly is the definition of the web front-end? This will influence how we design the back-end.
 * Does selection happen in Model?
 * Could the View Model be absorbed by the Model as namespaces?
 * Do we need to be more generic than "subset", to support other attributes at the View Model layer?

----

VizMap:
 * Visual Style - define Visual Property mappings, serializable, sits in VizMap
 * Mapping Calculator - given a View Model and Attributes, it tells you how to map; one calculator per attribute, provided when created; get/set attrName, Visual Property, apply(view)
 * Can you get at a discrete or continuous mapper from cmd line? Too much of the control is in the VizMap UI. This needs to be made public in order to support headless Visual Style creation.
 * Start up renderer; renderer provides list of Visual Properties into the VizMap UI to appropriately restrict
 * Does Renderer handle x,y,z? Are they Visual Properties?
 * User space: arbitrary coord system, +/- infinity
 * Device space:
 * Even headless mode has a renderer, e.g., for pdf export. A basic renderer can handle x,y,z for headless.
 * Layout sets coords by setting Visual Properties. The default renderer will provide the basic, core set of Visual Properties.
 * Where are these canonical VPs stored and how does the end user access these?
 * Should be able to query renderer on what is supported AND should be able to access canonical set of VPs.
 * Store immutable status of a VP in View Model so it is not overwritten by VizMap.
 * Node renderers are mapped by VizMap via attributes per node; the node renderer will determine which VPs are available in the UI.

Mini-Retreat Two

  • November 14-15, 2008
  • Genentech Hall, 4th floor, [http://pub.ucsf.edu/missionbay/ UCSF Mission Bay], 600 16th St. San Francisco, CA 94158

  • Alex's cell: 415-328-3967

Logistics

Topics for Discussion

  • ViewModel

    • How does this relate to widely diverse presentation use cases
      1. lightweight web rendering
      2. use of Cytoscape model components in other systems/products without view
    • Daniel's pluggable renderers
      • Questions for Daniel:
        1. What are the possible memory costs for having pluggable renderers (not detailed -- approximate)?
        2. What are the performance implications?
        3. How do we serialize these?
      • My (DanielAbel) notes are at DanielAbel/PluggableRenderers which discusses these issues a bit.

  • Begin Presentation API
    • UI Events and how they interact with Cytoscape Events
  • Work Layer (Command, Tunables)
  • some of my questions and ideas: ["Cytoscape 3.0/MiniRetreatTwo/DanielsQuestions"] (DanielAbel)

Agenda

Friday

9:15AM - 6:00PM

(Note: ISB group can't stay for Saturday, need view model nailed down and some talk about the web stuff)

  • View Model
  • Discussion of web-capability
  • Presentation

Saturday

9:30AM - 3:00PM

  • Renderers
  • UI Events
  • CyDataTables higher order semantics / operations (JOIN, etc)

Goal

  • Finish the ViewModel

Pre-meeting Comments

  • Should vizmapper and editor be covered at this meeting or is this for a later meeting? ->later

Meeting Notes

Review of architecture: (photo will be attached)

  • UI - Swing, headless
  • Application - will be thin layers with a bunch of Swing code to handle GUI or cmd line input
  • Work -
  • I/O -
  • View Model - State (color), Selection/Highlighting, Hide/Restore, Layout coordinates, supports serialization
  • Presentation -
  • Model -

Examples:

  • Layouts/Tunables - UI is inferred (Swing or cmd line)
  • MCode - can switch to Tunables? Pros and cons.
  • Selection:view - UI selection of graphics with visual feedback

  • Selection:subsets - selection gets passed to model

  • Presentation-based selection - presentation fires selection event, application listens, application tells View Model to define subset (a list that can be serialized), then Presentation layers can respond to subsets

Questions:

  • WIll the plugin dev have to write multiple UIs for each display type (Swing, web, cmd)? Will Tunables suffice for plugins? Or, should we have an abstract UI layer that handles a broader set of UI elements for the diverse front-ends.
  • What exactly is the definition of the web front-end? This will influence how we design the back-end.
  • Does selection happen in Model?
  • Could the View Model be absorbed by the Model as namespaces?
  • Do we need to be more generic than "subset", to support other attributes at the View Model layer?


VizMap:

  • Visual Style - define Visual Property mappings, serializable, sits in VizMap

  • Mapping Calculator - given a View Model and Attributes, it tells you how to map; one calculator per attribute, provided when created; get/set attrName, Visual Property, apply(view)
  • Can you get at a discrete or continuous mapper from cmd line? Too much of the control is in the VizMap UI. This needs to be made public in order to support headless Visual Style creation.

  • Start up renderer; renderer provides list of Visual Properties into the VizMap UI to appropriately restrict

  • Does Renderer handle x,y,z? Are they Visual Properties?
  • User space: arbitrary coord system, +/- infinity
  • Device space:
  • Even headless mode has a renderer, e.g., for pdf export. A basic renderer can handle x,y,z for headless.
  • Layout sets coords by setting Visual Properties. The default renderer will provide the basic, core set of Visual Properties.
  • Where are these canonical VPs stored and how does the end user access these?
  • Should be able to query renderer on what is supported AND should be able to access canonical set of VPs.
  • Store immutable status of a VP in View Model so it is not overwritten by VizMap.

  • Node renderers are mapped by VizMap via attributes per node; the node renderer will determine which VPs are available in the UI.

Outdated_Cytoscape_3.0/MiniRetreatTwo (last edited 2011-02-24 15:40:08 by PietMolenaar)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux