Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable persistence of selection info to the layout #6167

Open
alexcjohnson opened this issue Apr 7, 2022 · 6 comments
Open

enable persistence of selection info to the layout #6167

alexcjohnson opened this issue Apr 7, 2022 · 6 comments
Labels
feature something new P3 backlog

Comments

@alexcjohnson
Copy link
Collaborator

Part of #1851 - split out so we can discuss it separately

To make it possible to retain selections across redraws or create a new selection programmatically, the selection data should be part of the layout. This also means that when you finish a selection, in addition to the plotly_selected event you'll also get a plotly_relayout event. Probably no changes in the middle though (ie with plotly_selecting).

So what should these attributes look like? We need to describe the selection in data coordinates, including which axes / subplot we're selecting on; we need to support rectangular and lasso selections, as well as shift-select combinations of multiple regions and simultaneous selections on different subplots.

So I propose:

layout.selections = [{
    subplot: 'xy',
    type: 'rect',
    x: [5, 10],
    y: [-3, 6]
}, {
    subplot: 'x2y2',
    type: 'lasso',
    x: [5, 6, 5, 4, 2, 3],
    y: [9, 8, 7, 7, 8, 9]
}, {
    subplot: 'geo3',
    type: 'rect',
    geo: [[-113, 72], [-108, 22]]
}]

One tricky case here around geo subplots: for many projections when you pan or zoom, what was a rectangle is no longer a rectangle, what was a straight line is no longer straight. We may need to either (a) convert rect to lasso, and increase the density of points on the lassos when you pan/zoom after making the selection, or (b) keep track of the projection parameters in effect when the selection was made, so we can transform it to an accurate representation in the new projection. Option (a) will never be perfect, and will have occasional edge cases where it breaks down spectacularly, but (b) means adding a complicated bunch of logic to the drawing and point selection routines, and may have performance implications. mapbox may have some of this issue, as it supports rotating and tilting, though straight lines are still pretty close to straight when the map is tilted even if they are no longer x/y aligned. polar too, in the case where users set a nonzero inner radius.

@nicolaskruchten
Copy link
Contributor

will this stay coordinates with selectedpoints ?

@alexcjohnson
Copy link
Collaborator Author

Great question - when the user is creating or modifying the selection via GUI we'll set them both, but when rendering or rerendering the graph it seems like you might want it either way:

  • If you passed in trace.selectedpoints without layout.selections you pretty clearly want selectedpoints to stay there.
  • Unless you're trying to programmatically clear the selection, in which case you could detect that layout.selections is empty and wipe out trace.selectedpoints, but that could be cumbersome.
  • If you pass in layout.selections and the data has changed, most likely you want selectedpoints to update to the new set of points within the selection.
  • But maybe there's a case where you want to make a selection, then let the data evolve and see where those selected points go?

So perhaps we need a boolean attribute that explicitly says "when replotting, do I recalculate selectedpoints to match selections?" Like layout.syncselectedpoints or something? layout.syncselections? layout.reselect?

@nicolaskruchten
Copy link
Contributor

All good questions. Maybe they all roll up into "what to do if selectedpoints and selections don't match?" The options are, basically to trigger a relayout to force selectedpoints to match selections, or not, which could be controlled by a boolean.

@archmoj archmoj added the feature something new label Apr 25, 2022
@archmoj
Copy link
Contributor

archmoj commented Jul 6, 2022

Regarding selectedpoints, this part of the code looks pretty strange to my eyes:

function updateSelectedState(gd, searchTraces, eventData) {
var i, searchInfo, cd, trace;
// before anything else, update preGUI if necessary
for(i = 0; i < searchTraces.length; i++) {
var fullInputTrace = searchTraces[i].cd[0].trace._fullInput;
var tracePreGUI = gd._fullLayout._tracePreGUI[fullInputTrace.uid] || {};
if(tracePreGUI.selectedpoints === undefined) {
tracePreGUI.selectedpoints = fullInputTrace._input.selectedpoints || null;
}
}
if(eventData) {
var pts = eventData.points || [];
for(i = 0; i < searchTraces.length; i++) {
trace = searchTraces[i].cd[0].trace;
trace._input.selectedpoints = trace._fullInput.selectedpoints = [];
if(trace._fullInput !== trace) trace.selectedpoints = [];
}
for(i = 0; i < pts.length; i++) {
var pt = pts[i];
var data = pt.data;
var fullData = pt.fullData;
if(pt.pointIndices) {
[].push.apply(data.selectedpoints, pt.pointIndices);
if(trace._fullInput !== trace) {
[].push.apply(fullData.selectedpoints, pt.pointIndices);
}
} else {
data.selectedpoints.push(pt.pointIndex);
if(trace._fullInput !== trace) {
fullData.selectedpoints.push(pt.pointIndex);
}
}
}
} else {
for(i = 0; i < searchTraces.length; i++) {
trace = searchTraces[i].cd[0].trace;
delete trace.selectedpoints;
delete trace._input.selectedpoints;
if(trace._fullInput !== trace) {
delete trace._fullInput.selectedpoints;
}
}
}

Why both trace.selectedpoints and trace._input.selectedpoints are mutated?

@alexcjohnson
Copy link
Collaborator Author

Probably because we want the result to be as if we had called restyle providing the new selectedpoints, but we don't want the overhead of a full restyle call.

@jakeflorentine
Copy link

This causes a large issue when trying to sync selected points between multiple plots (non-sub-plots). If the selections array even had an ids option that would be great

@gvwilson gvwilson self-assigned this Jul 5, 2024
@gvwilson gvwilson removed their assignment Aug 2, 2024
@gvwilson gvwilson changed the title Persist selection info to the layout enable persistence of selection info to the layout Aug 9, 2024
@gvwilson gvwilson added the P3 backlog label Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature something new P3 backlog
Projects
None yet
Development

No branches or pull requests

5 participants