FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Change `legend` to accept `alpha` instead of (only) `framealpha`. · Issue #6363 · matplotlib/matplotlib · GitHub

Repository navigation

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

Closed

Description

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).

Activity

  1. efiring commented on May 3, 2016

    Member

    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.

  2. tacaswell commented on May 3, 2016

    Member

    I am with @efiring on this on.

  3. added this to the milestone on May 3, 2016
  4. added
    API: changesChanges to the public API, typically requiring deprecation.
    on May 3, 2016
  5. WeatherGod commented on May 4, 2016

    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)

  6. lzkelley commented on May 4, 2016

    ContributorAuthor

    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.

  7. tacaswell commented on May 4, 2016

    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)

  8. efiring commented on May 15, 2016

    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    API: changesChanges to the public API, typically requiring deprecation.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL