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 allows users to more directly edit plotted PVs. A user can "drag" individual points on the graph to new coordinates, updating PVs without having to edit each number/value by hand.

A new widget will be created which enables and configures this new behaviour. This will also require additions to the existing base graph code, but under a new Mouse Mode, so that it doesn't affect existing implementations, and usage of the new Widget is required to enable/view the new mode.

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

Architecture

Following discussion with Kay Kasemir, the general idea for the design is:

Overall Structure

A new InteractivePlot widget will be created, which is the same as (ideally inheriting from) the existing XYPlot, but has some additions to allow for customisation and enabling of the point-editing behaviour.

Interaction/point-editing behaviour

Direct changes to the base Plot.java class will be made to facilitate this new behaviour. Cursor coordinate data already exists, but it is protected, so the new code accessing it will need to exist within the same scope.
There's a lot of likely issues that could happen with the existing graph controls interfering with point manipulation. To avoid this, the "Edit Points" functionality would be placed within a new mouse mode in the graph toolbar. This also should minimise any impact on performance to existing usages of Plots, since the checks and calculations will only occur when a user is using that functionality.

New Widget

The new widget (InteractiveXYPlot?), inheriting much of the base behaviour from XYPlot, will have additional properties for the appearance of the local/edited plot traces.
Depending on how the Local PVs are generated (next section), they may need to be defined in the properties for the widget, alongside the original data traces.
This widget will ideally have some sort of flag to enable the otherwise-disabled-by-default behaviour, since this change shouldn't affect any existing implementations, but can still be used if desired.

Local PVs

Use pvs with names starting with loc:// to store a local copy of each of the plotted PVs. These can then be edited without affecting the "live" version.
These may have to be filled with placeholder data until the live PVs connect, then some script can copy the data over to the local PVs.

• 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.
This acts like another one of the existing Mouse Modes, so that editing points and other mouse interaction do not interfere.
However, as other interaction cannot happen simultaneously, points on the graph will only be able to be moved within the existing plot space

"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