-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Multiple legend positioning and sizing fixes #4160
Conversation
... src/lib/anchor_utils.js has the same logic
- do not list `dflt` in schema as their value depends on the legend orientation (and rangeslider ;) - improve attr descriptions - add comment for potential v2 improvement
... during calcdata loop, instead of in Legend.draw this allows us to 🔪 one loop over the data that plus some linting.
- set scrollBar enter attrs in constants file - rename textOffsetX -> textGap, add itemGap constants ... and use `bw` for borderwidth and `h` for d[0].height making formula cleaner in computeLegendDimensions
... which doesn't appear to do anything, and mv computeLegendDimension to separate step
- use fullLayout.(width|height) instead of ly(Min|Max) - use bw instead of opts.borderwidth - 🔪 double-empty-line - 🔪 some useless comments
... the current width didn't lead to any bugs, but it was too large in most cases. - make horiz. grouped / non-grouped logic more similar - DRY up x/y anchor logic
- mocks with negative x with orientation h - mock with small viewports - mock with legend beyond plotarea + scrollbox - mock with long item leading to x margin push
- see #771 - introduce measures _maxHeight, _maxWidth and _effHeight to track margin pushes, scrollbox and horizontal row wrapping - simplify (and fix) legend (x,y) constraint into graph width/height - introduce some l,r,b,y "max" margin-push logic - paves way to expose legend `maxheight` and `maxwidth` - update baselines! + from previous "new legend mocks" commit + and `horizontal_wrap-alll-lines` which now spans the graph's width
- when one sets autoexpand to false, fullLayout.margin are honoured no matter how big the legend gets. In this case, (I'd argue) the legend should NOT move from its provided (or default) (x,y) position to make it fit on the graph. - if some users want the legend to auto-expand the margin while keeping the provided/default (x,y), we could eventually add a `legend.fitinside` boolean attribute
- N.B. need to remove legend from splom test to get Lib.log counter right.
- which gives better margin pushes, fixes legendgroup_horizontal_wrapping mock - use per-item width for toggle-rect width in ALL horizontal legends, we could eventually compute "per-column" width, if someone finds it useful
Is this on the way to resolving #1199 or unrelated? |
@antoinerg would you mind reviewing this one? |
Thanks for the nice PR and the clear breakdown of your different commits 👍 Here's my first comment/question following Alex's suggestion on #3024 to:
@etpinard is this the expected behavior: |
Ok, here's what happens when you drag the legend to the right off the
Line 1824 in 6b0befe
as the legend width is larger than half the layout width.
plotly.js/src/components/legend/draw.js Line 108 in 6b0befe
snapping the legend back to the left. Now here's what happens when one drags the legend to the right past the plot area: here, the max horizontal legend width is computed with: plotly.js/src/components/legend/draw.js Lines 528 to 531 in 6b0befe
is It's not obvious to me how we should fix this problem. I'm thinking we could refine Line 1824 in 6b0befe
by considering the push-margin |
@etpinard It seems however that it does not snap back to the left enough: the item for trace 0 is clipped (the blue trace). |
Hmm. I can't replicate that. Can you check the |
The value for |
... to avoid race conditions leading to wrong legend position and size.
@antoinerg thanks very much for spotting that bug!! There was a race condition in Dragging around the which appears "ok" to me. There are still some less-than-ideal scenarios. These should be much easier to solve once #2704 is completed. Let me know what you think! |
This is a massive improvement for legend positioning. It seems like the several issues grouped in #771 are fixed as well as #4132 🎉
I think the most confusing scenario for users is when they set One last non-blocking comment: I noticed that Great job 💪 @etpinard 💃 💃 💃 |
Thanks very much for the review @antoinerg I pushed d043151 adding a description for Merging. |
I still see the problem of either choosing the legend overlapping the chart or legend with cut off text when legend labels are long. Would it be possible to have an option to wrap text in the legend or overflow auto with a max-width and a scroll bar? |
This PR essentially supersedes #3024, fixes #4132 and will resolve #771
In brief,
x
/y
attribute declarationslegend/draw.js
margin.autoexpand: false
in order to present a solution to a Legend overlaps since 1.11.0 #771 scenarioLib.log
calls that should make legend auto-margin / positioning edge cases easier to spotReviewers may be interested in reviewing
plotly.js/src/components/legend/draw.js
Lines 98 to 118 in 6b0befe
plotly.js/src/components/legend/draw.js
Lines 462 to 627 in 6b0befe
in
legend/draw.js
with their corresponding blocks on the current master:plotly.js/src/components/legend/draw.js
Lines 133 to 195 in 37e80cb
plotly.js/src/components/legend/draw.js
Lines 541 to 724 in 37e80cb
cc @plotly/plotly_js