Pipeline Browser Requirements: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
Line 33: Line 33:
=Drag and Drop=
=Drag and Drop=
* Dropping a file (from a file browser) should open an appropriate reader for that filetype as a root node in the current hierarchy.
* Dropping a file (from a file browser) should open an appropriate reader for that filetype as a root node in the current hierarchy.
::This might not work all the time until we get support for multiple servers. If ParaQ is already connected to an external server, we can't open a file from the local machine.--[[User:Mark|Mark Richardson]] 16:52, 31 Mar 2006 (EST)


=Musings=
=Musings=
* Support is currently designed for a single hierarchy.  Would we ever support mutliple hierarchies?  Example:  Save a snapshot in time, and be able to look back at that hierarchy (perhaps without displaying it in a render window) to cut/copy/paste from it.  Also, would it be helpful to be able to open a state file, and copy/paste items from that file into the current application, without having to connect/display the 'source' hierarchy.  This came up at Dreamworks a lot - artists wanted a way of opening a scene file without having it 'connect' to its sources, so they could make a quick change to a graph before re-submitting it to a render queue. In other words, they wanted a quick way to change something they knew was wrong (or, would take a long time to render, so they would have to wait for the results).  Adding this capability at the end was a pain - but designing this sort of 'disconnected editing' from the start would be nice.  It essentially amounts to supporting a 'really nice editor for the xml files that define our state'.  Just a thought.
* Support is currently designed for a single hierarchy.  Would we ever support mutliple hierarchies?  Example:  Save a snapshot in time, and be able to look back at that hierarchy (perhaps without displaying it in a render window) to cut/copy/paste from it.  Also, would it be helpful to be able to open a state file, and copy/paste items from that file into the current application, without having to connect/display the 'source' hierarchy.  This came up at Dreamworks a lot - artists wanted a way of opening a scene file without having it 'connect' to its sources, so they could make a quick change to a graph before re-submitting it to a render queue. In other words, they wanted a quick way to change something they knew was wrong (or, would take a long time to render, so they would have to wait for the results).  Adding this capability at the end was a pain - but designing this sort of 'disconnected editing' from the start would be nice.  It essentially amounts to supporting a 'really nice editor for the xml files that define our state'.  Just a thought.

Revision as of 16:52, 31 March 2006

Mouse (pointer) interactions

  • Left button
    • Double click 'opens' or 'closes' an item (toggling between the two states). The effects of 'open' and 'close' depend upon the item.
    • Double clicking or hitting enter 'activates' an item. In the case of tree views, this would expand/collapse an expandable item. Selection is used to show an item in the object inspector.--Mark Richardson 16:48, 31 Mar 2006 (EST)
    • File dialogue-like selection. Anything on the pipeline browser should be selectable by click or click-drag, modified by Shift or Ctrl keys, per typical file browser selections.
    • Cut, Copy, Paste support
      • Internal - can copy or 'instance' arbitrary groups of items. For example, pasting a subgraph onto a node would paste that subgraph onto the node as a direct connection. Pasting two separate subgraphs onto a node (at the same time) would paste two new subgraphs onto the node.
      • External
        • Paste from another running version of ParaQ should behave the same as Internal Paste above.
        • Other 'objects' that could be copied? It may make sense to support things like dragging an exodus (or other file type) from a file browser. See 'Drag and Drop Support' item.
  • Right Button
  • RMB click on a single element of the hierarchy should bring up a context menu with the following items (appropriately enabled, depending upon the current state):
   Note: an 'x' next to an item means that it is a 'checkbox' menu item.
 
 x On
   Display Properties ...   Ctrl+D
   -------------------------------
   Cut                      Ctrl+X
   Copy                     Ctrl+C
   Paste                    Ctrl+V
   -------------------------------
   Delete
   Delete Subgraph
   
   Note: The 'Display Properties' item opens a modal dialogue box that contains the widgets in 
         ParaView's 'Display' tab, found under the 'Parameters' tab for each filter.
   Note: The context menu trigger is different for windows and linux. On windows, the trigger
         is right button release. On linux, it's right button down.
  • Mouse 'hover'
    • When the mouse hovers over an element, it should display information that can be set by the user. Initially, this should display the first four items in the 'Statistics' group of the 'Information' tab (unde the Parameter tab for each filter): Type, Number of cells, Number of points, Memory (in MB)

Drag and Drop

  • Dropping a file (from a file browser) should open an appropriate reader for that filetype as a root node in the current hierarchy.
This might not work all the time until we get support for multiple servers. If ParaQ is already connected to an external server, we can't open a file from the local machine.--Mark Richardson 16:52, 31 Mar 2006 (EST)

Musings

  • Support is currently designed for a single hierarchy. Would we ever support mutliple hierarchies? Example: Save a snapshot in time, and be able to look back at that hierarchy (perhaps without displaying it in a render window) to cut/copy/paste from it. Also, would it be helpful to be able to open a state file, and copy/paste items from that file into the current application, without having to connect/display the 'source' hierarchy. This came up at Dreamworks a lot - artists wanted a way of opening a scene file without having it 'connect' to its sources, so they could make a quick change to a graph before re-submitting it to a render queue. In other words, they wanted a quick way to change something they knew was wrong (or, would take a long time to render, so they would have to wait for the results). Adding this capability at the end was a pain - but designing this sort of 'disconnected editing' from the start would be nice. It essentially amounts to supporting a 'really nice editor for the xml files that define our state'. Just a thought.