GroupIDProposal

From PathVisio Wiki

Contents 1 How it Should Work 2 Considerations 3 What We Need 4 Implementation Plan 5 Technical Details

How it Should Work

1. Select a bunch of objects
2. The user presses a key-combo (e.g Ctrl+G for group) or selection from context menu, main, menu or toolbar.
3. Something happens to the View (see below)
4. These objects will now have the same group id
5. Key use cases for Groups are listed here. Note, in particular, Use Cases 2, 5, 10, and 12, which are most relevant to PathVisio

Considerations

• What actually happens with groups? Do objects in a group automatically snap together, like magnets? Or do they just act as a whole (like group / ungroup in powerpoint)? I think the former makes more sense biologically (i.e. it is really a grouping of genes), but the latter is more user-friendly (more familiar)
• Can only DataNodes be in groups (i.e. for protein complexes) or also lines, shapes, etc.?
• In the end, more than one Group function is needed:

1. Generic Grouping - for all object types to allow coordinated editing/moving of groups of objects (like PowerPoint). This requires no change to the view, nor does it need to be saved. This is purely an editing feature. However, it could be built on top of the same Group framework built for the other use cases.
2. Grouped Views - for representing protein complexes or paralogs (like in GenMAPP pathways). This only applies to data nodes.

What We Need

• A unique identifier is needed for each group. For this we can copy the method used for generating the GraphID's
• We need to make sure new groupID's are unique, so we need to store existing groupID's in the current pathway in a list.
• For each groupID, we also need to maintain a list of objects that have it, to be able to find them quickly without scanning the whole list of objects.
• We are doing a walk-through of the code behind the Group API in Cytoscape on Tuesday, March 20th. This will help us devise an implementation plan for Groups in PathVisio, which I will add below

Implementation Plan

1. The Basics

• createGroup: creates a new node (the metanode) which is not a DataNode and associates it's graphID with the groupID set for each of the select (children) nodes. Should be able to work with objects of type node or annotation. I.e., annotations can have groupIDs. The metanode can serve as the visual representation of the group (i.e., when collapsed) or may be invisible (i.e., when expanded). The metanode (not the children nodes) should contain the groupStyle attribute, e.g., "stack", "box", etc. The metanodes coordinates will be determined as the simple center of mass for the selected nodes to be grouped.
• destroyGroup: remove metanode and clear groupIDs from children.

2. Functions

• Detect selection, pass object IDs
• Create node
  • associate child objects
  • determine coordinates
  • set groupStyle
  • collect edge references, pass to metanode

3. Interface, Controls

• Select one or more nodes or annotations
• Create Group by menu item, context menu item or ctrl-G
• Modify View by menu item, context menu item or hotkeys (maybe toggle through options via ctrl-G?)
• Add/Remove to/from Group requires group destruction followed by creation of new group
• Destroy Group by menu item, conext menu item or ctrl-shift-G (or on toggle list for ctrl-G?)

4. Expected Behavior

• When grouped, selection of a single child node brings up displays for that node (e.g., backpage), but movement (e.g., by click&drag) is applied to entire group. So, you can move the whole group in an expanded state with their fixed relative positions, or alter the view to one of a few implemented states (stack, box, collapsed, etc). Otherwise, you have to destroy the group if you want to move individual nodes independently.
• This single interface can then handle all the major use cases, including grouping for layout contols (like PowerPoint) and grouping for alternative views (like stacked paralogs) and grouping to simplify the network (like collapsing a subnetwork).

5. Saving Groups

• As nodes with attributes, the metanodes and their children can be saved in GPML. When read back in, PathVisio will have to respond to the groupStyle indicated as an attibute of the metanode in order to correctly render the group.

6. In Cytoscape

• Scooter Morris has devised a way to store and read groups in Cytoscape using xGMML. We should assess our GPML one more time before converting the archives to try to conform to the same approach, making it easier to go from PathVisio->GPML->Cytoscape->xGMML and back! This would be ideal. And now that Groups is fairly well settled in Cytoscape I think we can build it in PathVisio/GPML in a compatible way.

Technical Details

Changes Made

• org.pathvisio.model/GpmlFormat
  • Added methods:
  • mapGroupID()
  • updateGroupID()
• org.pathvisio.model/PathwayElement
  • Added methods:
    • getGroupID()
    • setGroupID()
• Added GROUPID to lists:
  • getAttributes()
  • setProperty()
  • copyValuesFrom()
• org.pathvisio.model/PropertyType
  • Added GROUPID definition
• org.pathvisio.model/Pathway
  • Generalized getUniqueID() to work with GraphIDs and GroupIDs

• org.pathvisio.model/ObjectType
  • Added GROUP = 7

• org.pathvisio.view/VPathway
  • Handle drawing-selection of groups

Group ID Phase 2

• Add label to Group - done
• Implement ctrl-G - done
  • Selection/Moving handling and visual cues
    • Implement Group Graphics, extending Graphics - done
    • Store group members Graphics (be sure to update!)
    • Use PathwayListener to update the store?
    • Implement Delete, check Copy/Paste
    • Ungroup
    • Display properties of Groups
• Implementing Styles (in parallel with Cytoscape)
  • No Style - keep coordinates
  • Stack - may be able to take advantage of align code from Cytoscape
  • Box - 2D stack, plus box shape
  • Collapse - replace children with Group as a node
• Ungroup
• Grouping in non-edit mode!