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

add entrywidth and entrywidthmode to legend #6202

Merged
merged 7 commits into from
Sep 23, 2022

Conversation

nickmelnikov82
Copy link
Contributor

The positioning options for legendgroups need to be improved. It should especially be possible to position legends horizontally further apart from each other. This PR adds a parameter legendtextwidth for trace and legend.

@nickmelnikov82 nickmelnikov82 changed the title add legendgroup width option add legendtextwidth option Jun 1, 2022
@alexcjohnson
Copy link
Collaborator

LGTM - aside from the revised name as suggested by @archmoj in #6202 (comment) I think we just want to use the new attributes in an image test.

@archmoj archmoj changed the title add legendtextwidth option add entrywidth and entrywidthmode to legend Aug 9, 2022
@@ -74,6 +74,19 @@ module.exports = {
'Sets the amount of vertical space (in px) between legend groups.'
].join(' ')
},
entrywidth: {
valType: 'number',
min: 0,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should provide a dflt for this attribute.
However using zero looks confusing.
@alexcjohnson

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually think it's nice to use zero to mean "automatic - use the text width," if we document that.

Alternatively, we could have a third value for entrywidthmode, perhaps 'auto', that means we use the text width. Then the logic would be:

  • If a nonzero entrywidth is provided, entrywidthmode defaults to 'pixel'. If not, it defaults to 'auto'.
  • If entrywidthmode is 'auto' we don't coerce entrywidth.

That feels unnecessarily cumbersome to me though. Only reason I can think of that would justify this is if we want to actually support a width of zero. Any reason someone would want that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to use zero as the auto default the min namely for the pixel mode should be a value greater or equal 1 not zero IMHO.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be confusing, wouldn't it? We'd document "Use 0 to size the entry based on the text width" but document a min of 1... yet if you explicitly set it to 0 it would work, because we'd throw out the 0 and replace it with the default 0.

Let's keep this simple, and consistent with colorbar.len and colorbar.thickness - min: 0 and no max regardless of entrywidthmode, the only difference being that 0 has a special meaning we'll document. If it turns out that certain values (either very small or very large) cause problems worse than "it looks bad," we can address that during the drawing process when we know more than we do at the supplyDefaults step.

@archmoj
Copy link
Contributor

archmoj commented Sep 23, 2022

Thanks for the PR @nickmelnikov82 🎖️
💃
Merging to master...
I'll open a PR shortly after to address few remaining items.

@archmoj archmoj merged commit bd1d6bd into plotly:master Sep 23, 2022
kMutagene added a commit to plotly/Plotly.NET that referenced this pull request Feb 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature something new
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants