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

Change legend to accept alpha instead of (only) framealpha. #6363

Closed
lzkelley opened this issue May 3, 2016 · 6 comments
Closed

Change legend to accept alpha instead of (only) framealpha. #6363

lzkelley opened this issue May 3, 2016 · 6 comments

Comments

@lzkelley
Copy link
Contributor

lzkelley commented May 3, 2016

It seems this parameter name comes from the internal parameter being set, e.g. leg.get_frame().set_alpha(0.5), but it seems like it would make much more sense from an API perspective if one could simply use the argument alpha, i.e.

plt.legend(alpha=0.5) instead of plt.legend(framealpha=0.5).

@efiring
Copy link
Member

efiring commented May 3, 2016

The problem is that there is much more in a legend than the frame; a plain "alpha" kwarg would imply changing the alpha of all components of the legend.

@tacaswell
Copy link
Member

I am with @efiring on this on.

@tacaswell tacaswell added this to the unassigned milestone May 3, 2016
@WeatherGod
Copy link
Member

Now, that being said, is having a "alpha" keyword to adjust the alpha of
everything in the legend all that bad of an idea?

On Tue, May 3, 2016 at 7:04 PM, Thomas A Caswell notifications@github.com
wrote:

I am with @efiring https://github.com/efiring on this on.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#6363 (comment)

@lzkelley
Copy link
Contributor Author

lzkelley commented May 4, 2016

Yeah, I totally see your points. At the same time, I feel like the effect of framealpha is the most basic type of transparency someone would want (presumably why its the one implemented). The most basic application of legend transparency wouldn't necessarily want to change the appearance of the symbols, or decrease the readability of the labels... instead just the background opacity.

@tacaswell
Copy link
Member

This is a common sort of trade off in API design, the 'do what I mean' vs 'do what I told you'. The upside of mapping alpha -> framealpha is that in some (but not all) cases that is the 'do what I mean'. However, the down side is that with the rest of the API, passing in alpha to a function applies to all of the artists created by that call.

That said, looking at the set_alpha method on Legend (and the various Packer classes we use for layout of the legends) they do not actually work and need to broadcast to their children (a-la #3944)

@efiring
Copy link
Member

efiring commented May 15, 2016

I'm going to close this. For the time being, I think we need to stick with the moderately ugly but descriptive framealpha. How the ubiquitous set_alpha method should be handled for all sorts of constructs like the legend is another topic--probably big enough to warrant a MEP. Do we really want every set_alpha to cascade down through all levels? I suspect the answer to this will not be as straightforward as one might expect.

@efiring efiring closed this as completed May 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants