Design of Lookmarks

From ParaQ Wiki
Revision as of 14:50, 6 February 2007 by Etstant (talk | contribs)
Jump to navigationJump to search

The following discusses how the user should interact with lookmarks and the design issues that arise.

What can you save with a lookmark?

  • the state (including displays) of the sources (and all their inputs) that are visible in the current view.
  • time
  • camera state
  • center of rotation

What doesn't a lookmark save? Note: these won't be a priority in the first-pass implementation of lookmark, but within the lookmark framework it will be possible to save them in the future.

  • multiple views
  • plots - though it would be nice to be able to save a lookmark of plots as well

Creating a Lookmark:

  • There will be a "Create Lookmark" wizard available from the menu just like custom filters. It will consist of a single page with a line widget for the lookmark's name followed by checkboxes (checked by default) for whether or not to save: the reader(s), camera properties, and time. A button at the bottom will create the lookmark (for the currently selected view), adding it to the Lookmark Inspector (see "Managing Lookmarks").
    • Aside: Why allow the user to turn on/off saving time, camera, and reader? Consider the following use case. The user opens some data, manipulates the camera to find an area of interest, then wants to apply a set of operations but retain the current time, camera, and reader. The reason he can't use a custom filter is because he wants certain internal display properties of the lookmark's filters to be restored. When would the user want to save time? When he comes across something interesting in his data at an exact position, timestep, etc that he wants to save for later or export to a file to share with a colleague.
  • There will also be a second way of creating a lookmark. Each view will have a lookmark button next to its frame-splitting icons that will display the Lookmark wizard described above. In thinking about ways for the lookmark wizard not to have to be displayed, here are some options:
    • Have the reader|camera|time options be located in the application settings so that pressing the lookmark button will simply create a lookmark based on what those values are set at. Con: may be too hidden if the user finds himself changing these options frequently.
    • Have a checkable drop-down menu next to each view's lookmark button that lists the reader|camera|time options. Con: Do we sync the state of this menu across all the views or not? Either way, its probably not going to be obvious to the user.
I've decided that instead of giving the user the option of what to save when a lookmark is created, just save everything by default, then provide them with the option in the lookmark inspector to restore the saved time/camera/reader(s) as they see fit. This way any lookmark can act like a filter-only (i.e. customfilter+displays) object. So we'll take out the checkboxes in the creation dialog. But I'm going to add a text field to allow the user to write comments that will be saved with the lookmark.
In the creation dialog we could have a checkbox at the bottom that says something to the effect of: "Do not display this dialog box in the future. Create lookmark automatically using a default name."
--Eric 15:40, 06 Feb 2007 (EST)

Invoking a Lookmark:

  • All other sources in the view in which the lookmark is being displayed will be set invisible first
  • As a first pass, if the lookmark includes readers, it will first try to open the data file at the path it was at when the lookmark was created. If the file(s) have since been moved or deleted, the user will be asked to select a new one from a browser. But in the future we want a way for a lookmark that includes readers to be applied to a different dataset than the one it was created with.
  • The sources that make up the lookmark are added to the pipeline browser just like when state is loaded manually
  • By allowing lookmarks (made up only of filters) to be applied to different datasets, we become susceptible to robustness issues. For example, what happens if a lookmark's filter is colored or thresholded by a variable that isn't in the new dataset? The user will get an error message and paraview should not crash. If we improve the error dialog some, this may not be a big issue. After seeing the error, the user can go and select another array to color by or threshold by.

Managing Lookmarks:

A Lookmark Inspector (a dockable window) can be displayed (where? laid out vertically to the right of the render windows?). Here the user will be able to import, export, and remove lookmarks. Lookmarks can be organized hierarchically and each lookmark entry will include metadata about that lookmark (a thumbnail preview, name, comments, dataset(s) if any, time of creation(?), ...).

Following the relationship between the Pipeline Browser and the Object Inspector, there will now be two windows: a Lookmark Browser and a Lookmark Inspector. The browser will display the icon and name of each lookmark (in a list as a first pass then as an organizable tree structure). It will be responsible for importing, exporting, removing, creating(?) lookmarks. The inspector will then display the metadata for the currently selected lookmark. I'm still thinking about what sort of metadata the user might want but here are some ideas.
    • an enlarged lookmark icon
    • comments (the the user made about the lookmark at the time of creation, but that can be edited as well)
    • the name(s) of the dataset(s) used to create the lookmark
    • whether or not to restore the lookmark's time when loaded
    • whether or not to restore the lookmark's camera properties when loaded
    • whether or not to restore the lookmark's reader(s) (or use the exisiting ones) when loaded
    • the version of ParaView it was created on (this might be important for backwards compatibility)
    • data/time it was created
    • a snapshot of the structure of the pipeline it will load

--Eric 15:40, 06 Feb 2007 (EST)

Dealing with Filter-Only Lookmarks:

As a first pass, lookmarks will save and restore any readers that existed at the time of creation. But we also want to be able to use a lookmark on a different dataset. Currently this is an unresolved issue. Since a lookmark is just a subset of state, how do you specify inputs?

Dealing with Multiple Views:

As a first pass, a lookmark can only be created of a single (the current) view.

Dealing with Multiple Inputs:

We eventually want to be able to create a lookmark with multiple readers or filters as inputs but as a first-pass we will only support one.

Miscellaneous: Most of these features will have to wait until 3.2 if they are implemented at all.

  • A right click on a lookmark's icon in the toolbar displays a menu with options to remove the lookmark, and perhaps a "Preview" option that displays a larger image of the icon (I think VolView has something similar)
  • Provide an advanced option (maybe in the application settings) which, when set, displays lookmarks in a new view when they are invoked
  • Provide a preview of the internal pipeline of a lookmark (similar to the one in the Input Editor)
  • Lookmarks, like custom filters, from a previous ParaView session should automatically be loaded into the toolbar.
  • A one-click mechanism for turning on/off the visibility in a view of a lookmark that has already been created (i.e. added to the pipeline browser).
Retrieved from "http://www.paraview.org/ParaView/index.php?title=Design_of_Lookmarks&oldid=3188"