Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Updated patch to not override alpha on edgecolor if set to none#1938

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed

Conversation

cimarronm
Copy link
Contributor

Addresses issue#1934.

@pelson
Copy link
Member

Hmmm. I'm not sure about this. This will result in some strange behaviour. The following two snippets will behave very differently:

# set the edgecolor to black, but make it completely transparent>>> patch.set_edgecolor((0, 0, 0, 0))>>> patch.set_alpha(0.5)>>> print patch.get_edgecolor()(0, 0, 0, 0)
# set the edgecolor to red, but make it completely transparent>>> patch.set_edgecolor((1, 0, 0, 0))>>> patch.set_alpha(0.5)>>> print patch.get_edgecolor()(1, 0, 0, 0.5)

It may be that the work stemming from#1899 should address this problem when dealing with alpha and color definitions.

@cimarronm
Copy link
ContributorAuthor

@pelson: You are correct. The problem is that there is no special color designation for no edge. Instead 'none' gets translated inset_edgecolor into (0,0,0,0) and it becomes black with alpha=0 (i.e. one loses the context that it was no edge).

Thereal solution I see is no allow a color designation of none. But that is not straightforward with the current code that I can see. There are three posibilities I can readily see:

  1. Allow color to be a RGBA tuple or 'none' - code handling the color value gets a bit ugly as you have to check if it is a string or list/tuple.
  2. Allow color to be a RGBA tuple or None - much cleaner implementation but the problem is the existing setter/getter UI associates None with a default color rather than no color (it would have been much better to use 'default' or something like that instead of None for the setter IMHO but it is what it is).
  3. Allow color to be a RGBA tuple but use a special tuple value for a no-color designation, e.g., (-1,-1,-1,-1) - this seems like the best solution to me but not sure what your/others opinion on it

Do you think one of the three is the way to go or do you see an alternative approach?

@Westacular
Copy link
Contributor

Actually, the wayfacecolor is handled in Patch served as a template for whatedgecolor ought to do -- internally preserve whatedgecolor was originally set to, so in cases likeedgecolor='none', it knows to not let alpha override that (the logic for this is already present incolorConverter.to_rgba()). Commit461233c in#1954 makes this change.

@cimarronm
Copy link
ContributorAuthor

Sounds good to me. I will close this PR

@pelson
Copy link
Member

Thanks to@cimarronm and@Westacular for looking into this murky part of color handling 😄

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

3 participants
@cimarronm@pelson@Westacular

[8]ページ先頭

©2009-2025 Movatter.jp