Repository navigation
Interactive plot styling #2237
Description
I am concentrating discussion on the matplotlib-devel list over the last few days into this issue.
PR #2236 adds requested style sheet support, which is most of the necessary work done.
It would be a great enhancement to have a way of interactively selecting the style sheet applied to a plot.
In addition, a style explorer along the lines of ColorBrewer would be very nice.
Activity
dpsanders commentedon Jul 21, 2013
I have added an IPython issue here to add code completion for dictionaries. This will enable the following idiom:
which will then present a dropdown with a selectable list of keys!
I think this will be a nice enhancement encouraging people to play around more easily!
tacaswell commentedon Jan 17, 2014
This is hard because of the lack of semantic information in the artists.
pelson commentedon Jan 17, 2014
I'm in favour of the principle, but whether somebody will be able to achieve the goal is an unknown. I'm going to close the issue in the hope that it inspires somebody to actually do it 😉
tacaswell commentedon Jan 17, 2014
I think this should be kept open because this is very closely related to the discussion on the mailing list started by @jakevdp.
pelson commentedon Jan 17, 2014
My argument is whether having an "issue" closed in github prevents work being done. I'd argue that a good (i.e. worthwhile) feature will still bubble to the top of somebody's agenda and actually get implemented irrespective of whether the ticket exists, so why have it? On the other hand, having a list of bugs which need fixing in an issue tracker is certainly valuable, as it gives us an opportunity to look over them meaningfully before we make a release to review what still needs doing, and what has been fixed in the latest iteration.
Again, just my 2 cents, so please feel free to re-open if you disagree.
tacaswell commentedon Jan 17, 2014
I can see the downside of having too many inactive feature requests in the issue list, but I also worry a bit about aggressively closing them as it can send the message 'we don't care about your requests'. This is more relevant for small things that make user's lives easier but the dev's don't see because they don't use that bit of the code in their daily work. I would expect big features to bubble up, but not the small stuff. The library gets used in ways I don't think anyone could have imagined.
I am not sure where the threshold should be, but it I am clearly more hesitant to close than you are 😄
efiring commentedon Jan 18, 2014
@pelson, @tacaswell, I very much appreciate the vigorous issue checking and closing by both of you; I was beginning to despair that the issue stack was hopelessly out of control. It is still far too large. This is exacerbated by the poor design of issue tracking in Github, but we are stuck with that. Regarding your exchange above, I favor more closings rather than fewer. Otherwise too much time is wasted in repeatedly going through the issue list looking for the things that one can fix, and that really need to be fixed.