New Widget: Interactive Graph

[JonFijalkowski]

Just as a foreword, I'm pretty new to the Phoebus repo, so a lot of this could be well off the mark - please correct me if there's anything incorrect/not possible, or if there's anything I'd not considered.

Proposal

This is a proposal / Story Issue for the creation of a new interactive graph widget for Phoebus. It's a feature that's been requested by our users at ISIS, and I think this might be something that could be contributed to Phoebus at large, since its function is reasonably generic, and therefore usable across many control systems.

Any feedback you can provide would be greatly appreciated, whether it's technical advice, or just registering of interest in this feature being added.

The main goal of this is to create a new XYPlot / graph-style widget which can be interacted with, allowing a user to "drag" individual points on the graph to new coordinates, updating the PVs without having to edit each number/value by hand.

A mockup for what this might look like using Excel, with the second "edited" line drawn in a blue, dashed line

Architecture

Overall Structure

There are a couple main ideas I had for what "type" of widget this will be, whether it be a whole new combined input/display widget, or a separate mouse-controlled widget which is overlaid over an existing graph

Combined/single interactable graph widget

The idea for this is to have all the display and behaviour happen within the same widget. Inheriting from the XYPlot widget so the existing graph behaviour/display doesn't have to be done over again. Then the remaining functionality (mouse interaction, buttons, is included on top of that.

Pros:

• Single widget, self-contained
• Doesn't have coupling between widgets
• More direct access to XYPlot (which may simplify implementation for things such as selectively rendering/plotting the "edited" series)

Cons:

• Blurs lines between display and input widgets
• Inheritance may not be useful for implementation

Separate overlaid point-editing widget

This would be a separate widget to the XYPlot displaying the PVs, and instead is placed on top of the graph, and handles the mouse inputs to change PVs.

Pros:

• Doesn't need any existing graphs/plots to change as much.
• Separation between display and input widgets remains
• Less likely to mess with existing screens and plots, since it is a secondary layer

Cons:

• Potentially messy interacting and connecting to other widgets
• Old screens will still need extra series added to their graphs for the "edited" series
• Coupling between two separate widgets instead of inheritance
• Since it isn't a display widget, doing anything graphical with it may be complicated.
• Have to make sure the graph is lined up with the extra widget, and that the coordinates are calculated correctly (otherwise it's useless as a tool to replace manual value changing)

Local PVs

use pvs with names starting with loc:// to store a local copy of the PVs. These can then be edited without affecting the "live" version.

• faster response time (more closely represents/follows mouse pos) since it can be updated without any delay a "live" PV would experience
• changes are only kept locally - having the widget change a "live" copy means others on the same screen will see those changes happen as well, rather than just getting the new changed "original"
• less bloat to "actual" pvs - we don't need to send or store any of these local changes other than when doing the save

Interaction

Graph

Each point on the graph has a square/marker on it - this would be the expected

One check for the nearest point (which will be "selected" if within some minimum range) would occur on a mousedown, rather than continuously triggering as the point is moved. This would otherwise run the risk of it picking a different point as you move one over another, and slow down performance constantly carrying out that check.

"locking" axes

There are cases where a user may only wish to make changes in the x or y axis (and some may have fixed x axes/timeseries), so there should be a way to "lock" axes to prevent any movement in that direction while dragging a point.

Buttons

"Edit"

Enables the ability to click & drag points on the graph, so that the user only makes changes when they want to, and to allow normal usage/interaction with the graph when edit mode isn't active.

"Discard changes"

Button to revert any changes made to the local PVs, so they match the existing "original" PVs. Useful if lots of changes were made but were unnecessary, lots of mistakes were made, or if changes were made by mistake.

"Undo"

Undoes the most recent change. Useful if a single mistake was made, but undoing all changes would be too excessive. This would require a set/list of older copies of the local PVs, and there would need to be an extra copy per number of undos we allow in a row.

"Save Changes"

Our users don't want changes to immediately be made to the "live" version of the PVs being displayed/edited.
This button means that once all the desired changes have been made on the graph, a single PV update is pushed, changing all the "live" values in one go. (Partly this is assuming that the provided PVs are a list or similar, rather than a large set of individual PVs)

UI design

Buttons

Different coloured to make sure they're not mistaken for each other?
RED for discard, green for save, blue for edit, yellow for undo?
positioned to the side of the graph, potentially include icons in them (or just only be icons)

Secondary/"edited" line

A dashed line will be useful to differentiate it from the "original" line, and could also be coloured differently to make it even more distinct. However, this means if it is plot on top of the original, it may not look particularly good. Also, it may be worth drawing the edited line thinner than the original so it doesn't cause graphical weirdness when plotted next to the original.
A different colour could be used to make them more clearly separate, but this could cause confusion if there are multiple plots in the same graph, and the new line's colour matches another which already exists. The edited line colour could be set using a property of the widget to avoid this.

Coordinates

When dragging (or at all times while editing), it could be useful to display the cursor's coordinates beneath/next to it. This is already possible when using the graph toolbar, but having it available/active within edit mode would make more precise changes easier.

Indicators for activity

Given that the graph plot may be slow to update, we may want some way to show the user that they are still editing values/dragging a point. This could be done by having a simple circle, cross or other indicator under the cursor to show the point where the value/line will move to.

Existing functionality

XYPlots already have the ability to display a marker line, which can be moved by clicking and dragging. Its position is determined by a PV, and a local one is used in one of the example Phoebus screens, so adapting this to be able to edit X or Y values, and update a list PV instead of a single scalar aren't too large a leap.

XYPlot's toolbar also allows you to show guidelines and live coordinates of cursor position, so reusing this for when moving a point on the graph would make changes more accurate.

Future/Larger Scope work

• Selecting and editing multiple points at once
• Additional manipulation tools (eg: smoothing by different curve types/equations)
• Adding data points (inbetweens, as well as adding points according to a certain curve type)
• Plotting/Editing values produced by functions, not just direct plotted PVs