-
Notifications
You must be signed in to change notification settings - Fork 68
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
Proposed new color names #2065
Proposed new color names #2065
Conversation
@doutriaux1 @danlipsa I would like to propose refactoring the color names. The current color names unfortunately were inconsistent and hard to read. I followed the color names syntax as I found in some other tools specifically in R domain (https://www.nceas.ucsb.edu/~frazier/RSpatialGuides/colorPaletteCheatsheet.pdf) but I am open for suggestions. This in preparation for 3.0 release so, yes it will break the backward compatibility, but if you all insist, I can add a alias for now as well. Also, over all the names got shorter, I deleted 277 characters and added 257. Thoughts? |
@aashish24 yes, let's add an alias. Also let's add matplotlib palettes especially |
@aashish24 I will add viridis and other matplotlib colormaps |
@doutriaux1 if its okay, let me add that (and alias) so that we can have one branch for color maps. |
thanks @doutriaux1 so sounds like these changes are liked which is great. I think it will really help boost vcs usability as we all are making the API better |
i was going to do it in that branch but go ahead. Thanks! |
roger that |
b23aa8b
to
2512eb0
Compare
@doutriaux1 @danlipsa this should be ready for review |
Also, added matplotlib colors (plasma, inferno, magma, viridis) |
@@ -4961,6 +4979,15 @@ def setcolormap(self, name): | |||
# updateVCSsegments_flag = args[1] | |||
# except: | |||
# updateVCSsegments_flag = 1 | |||
# Python < 3 DeprecationWarning ignored by default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aashish24 I don't think this should be here. We should issue this warning whenever the user sets the colormap instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks. @doutriaux1 I am bit confused. Currently the warning is in "setcolormap" instead. Look at the code at line 4953.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
graphic methods can have colormaps as well, is that going to be triggered if I do:
import vcs
b = vcs.createboxfill()
b.colormap = "white_to_red"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remember there are 3 levels to look for the colormap used.
1- graphics method
2- canvas
3 vcs module
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remember there are 3 levels to look for the colormap used.
1- graphics method
2- canvas
3 vcs module
Okay, let me add something to the code to make sure that we can map old to new regardless of where we set the colormap.
@aashish24 also the initial.attributes in Share is just ridiculously long, we should reformat it to a straight json dump. |
@aashish24 let's also use this PR to switch the default colormap to |
we could do that. I made a pass so that its pretty. Even though its long, its easy to read. I am fine either way. |
@doutriaux1 okay if we do it in a separate PR to keep pr's small? |
that's fine by me |
d9af7ac
to
a31dbc4
Compare
@doutriaux1 I uglified the initial attributes as suggested, that made the file size three times smaller, I liked your idea, thanks. This branch is ready for review now. |
00c7a66
to
018e8d7
Compare
018e8d7
to
8e3fc58
Compare
@doutriaux1 @danlipsa @williams13 I am going to push one more change for backward compatibility and then this will be ready for review. |
Basic content checks passed! Branch-at: 8e3fc58 |
@aashish24 The new names LGTM 👍 |
Do: test |
Testing commands handed to buildbot. Branch-at: 8e3fc58 |
a2ea896
to
89c3c52
Compare
@doutriaux1 @danlipsa okay so I updated the code so that it will be backward compatible no matter how we set the colormap. Please have a look at the code now. Its ready for the review 🃏 |
@doutriaux1 @danlipsa ping |
@aashish24 LGTM 👍 i would squash the commits though |
Do: test |
Testing commands handed to buildbot. Branch-at: 89c3c52 |
@danlipsa each commit is different and brings new stuff to the code base. I am not entirely sure that in this particular case squashing makes sense. Actually if you look the branch there are only 4 commits as I rebased so the older commits are gone if that's what you were referring to. |
@aashish24 Why would you have 'Added backward compatibility support' and 'Updated backward compatibility' as commits by themselves? Also, why would you have 'Proposed new color names' and 'Updated to use new color names' as separate commits? |
@aashish24 does |
the first commit added the backward compatibility in a separate way which is different than the last commit on the same topic. I kept old to keep that history of what things I have tried. The proposed color names just added new names and the updated to use new color names updated tests to use new names vs the old ones. I am fine with squashing this into one. |
@doutriaux1 no it does not. I thought about it and I don't think with direct assignment like this we can issue a warning. Now we can issue a warning afterwards when we actually try to use the color name but it may not be as useful (especially since we user colormap at different places and very differently). Managing that could be lot of work. I think we document it and send an email to the mailing list that may suffice to inform the user but I am open for ideas. |
@aashish24 it should be a |
I see that but then I guess I have to create a override function for all graphics method (there is no common baseclass?) Its more core (canvas and all other graphics methods etc..) but i am fine with that if that is more useful. |
thanks @doutriaux1. I am wondering if we should have a base class for graphics methods. Thoughts? @doutriaux1 @danlipsa |
I've been thinking about it for a while, there's something similar to that in vcsaddons, we should inspire ourselves from it. |
* Proposed new color names * Added backward compatibility support * Updated to use new color names * Added perceptual sequential matplotlib colormap * Updated backward compatibility
No description provided.