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.

I am with @efiring on this on.

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)

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.

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)

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.