Design of Lookmarks

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. 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.

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.

Berk, should we ask the folks at elevation design to create the icon for creating a lookmark?"

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 dock widgets on the right side of the screen: a Lookmark Browser and a Lookmark Inspector. The browser will display the icon and name of each lookmark. It will be responsible for importing, exporting, removing, creating(?) lookmarks. The inspector will then display the metadata for the currently selected lookmark(s). When multiple lookmarks are selected, it will only display the properties that it makes sense to, such as whether or not to restore their time|camera|reader(s) when invoked. This way the user doesn't have to visit each lookmark to modify these settings. 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

Question - how important is it to people to be able to organize lookmarks into a hierarchy/tree structure? I know of one user here who wants it. What I may do is put it on the stack for 3.2.

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:

• Lookmarks, like custom filters, from a previous ParaView session should automatically be loaded into the toolbar. This has been implemented. When the application exits, the contents of the lookmark inspector is converted to an XML format where each lookmark is its own element with attributes (name, comments, etc). It also has a nested element that is the server manager state represented as XML. I'm saving all this in the pqSettings under the key "LookmarkInspectorState". Then when paraview is launched again, this string is parsed and used to populate the lookmark browser.
• When a reader is selected either in the Pipeline Browser or in the Statistics Inspector, all lookmarks associated with that data could get highlighted in the Lookmark Browser.

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

• Be able to drag a lookmark from the lookmark browser to the view you want it displayed in.
• 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)
• 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).