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

Reversed colorscale #1933

Merged
merged 17 commits into from
Dec 10, 2019
Merged

Reversed colorscale #1933

merged 17 commits into from
Dec 10, 2019

Conversation

emmanuelle
Copy link
Contributor

@emmanuelle emmanuelle commented Nov 29, 2019

Closes #1681

@nicolaskruchten
Copy link
Contributor

To record my verbal comments from earlier: this looks right from the point of view of ...colorscale='Viridis_r' but breaks the current symmetry we have between ...colorscale='Viridis'... and ...colorscale=plotly.colors.sequential.Viridis.... It would be great if all the colorscales in plotly.colors also had a _r variant.

The tricky bit is that this would include all the colorscales in plotly.colors.sequential/diverging/cyclical and all those same scales as they appear in other collections like plotly.colors.carto etc (if possible!)

@emmanuelle
Copy link
Contributor Author

I need to add a couple of tests as well, but let's see first what percy thinks about this (I did not include the reversed colorscales in the swatches, so there should be no change).

@@ -33,7 +33,7 @@ def _swatches(module_names, module_contents, template=None):
marker=dict(color=colors),
hovertemplate="%{y}[%{customdata}] = %{marker.color}<extra></extra>",
)
for name, colors in reversed(sequences)
for name, colors in (sequences)
Copy link
Contributor

Choose a reason for hiding this comment

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

i actually kind of liked the old order, otherwise they read bottom up...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh good catch, I had modified this while debugging and then forgot to change it back.

@nicolaskruchten
Copy link
Contributor

looks great to me! could you revert the codegen'ed piece of this plz though leaving just the changes to the core lib in color an util? 💃

@emmanuelle
Copy link
Contributor Author

Not sure I understand your comments about the codegened piece: a lot of files are modified because docstrings are modified. Shouldn't we keep these modifications? Or are they going to be rolled out by something else? (the release etc.). Or should I just revert the package.json-lock changes? Please bear with me :-).

Copy link
Contributor

@jonmmease jonmmease left a comment

Choose a reason for hiding this comment

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

Thanks @emmanuelle. I added a few comments of things that I don't think should be changed in this PR. Let me know if it doesn't make sense.

@@ -15147,7 +15147,7 @@ def add_violin(
or greater than 4*Q3-3*Q1 are highlighted (see
`outliercolor`) If "all", all sample points are shown
If False, only the violins are shown with no sample
points and the whiskers extend to the range of the sample.
points
Copy link
Contributor

Choose a reason for hiding this comment

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

@emmanuelle, I don't think this docstring change should be coming in this PR. Maybe try rerunning codegen in case you had a different schema around when you generated this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually #1988 already removed those. I think they were not added at the right place (I think it was a community PR, I must have merged it without thinking that this should have been in the codegen instead.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What do you suggest to do here @jonmmease ?

Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like this code was somehow generated from the schema for plotly.js 1.51.2 (which this branch shouldn't have yet). In any case, why don't you try merging in master and then running codegen again. Hopefully then the diff will only show the colorscale docstring changes.

@@ -9,26 +9,26 @@
"resolved": "https://registry.npmjs.org/3d-view/-/3d-view-2.0.0.tgz",
Copy link
Contributor

Choose a reason for hiding this comment

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

It shouldn't be necessary for this file to have changed unless you're changing the bundled version of plotly.js. Could you revert it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This one will go away when rebasing on master. I don't think I changed the bundled version of plotly.js but I ran the codegen to update the docstrings.

Copy link
Contributor

Choose a reason for hiding this comment

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

When you run codegen, are you using python setup.py codegen? This shouldn't trigger any JavaScript/npm logic that would alter this file. When you merge in master, go ahead and accept masters version of this file as-is.

@@ -10495,27 +10495,27 @@ module.exports = function(opts) {
/* 10 */
Copy link
Contributor

Choose a reason for hiding this comment

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

Revert these changes as well

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok

@emmanuelle
Copy link
Contributor Author

OK, I ended up with a big git mess. I'll work on it later this evening, hope it won't be too late

@jonmmease
Copy link
Contributor

No worries, I'll do the release tomorrow morning. Thanks for working through it!

@emmanuelle
Copy link
Contributor Author

emmanuelle commented Dec 10, 2019

Not there yet but making progress :-)

@emmanuelle
Copy link
Contributor Author

Hey @jonmmease I think this one is ready now. Thank you for your patience!

@emmanuelle
Copy link
Contributor Author

Hum, not quite yet, CI not happy.

@jonmmease
Copy link
Contributor

Thanks @emmanuelle! I made one small testing change in 0c555f6 to allow all of the *_r colorscales to be included in the parametrized tests.

@jonmmease jonmmease merged commit a17e6a3 into master Dec 10, 2019
@nicolaskruchten nicolaskruchten added this to the v4.4.0 milestone Dec 10, 2019
@emmanuelle emmanuelle deleted the reversed-colorscale branch March 31, 2020 16:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

add support for the _r convention to reverse colorscales
3 participants