Skip to content

Re-instate BboxConnectorPatch fill #8075

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

Closed
wants to merge 5 commits into from

Conversation

dstansby
Copy link
Member

Fixes #8059. Also adds a simple image test for BboxConnectorPatch, which is currently not tested.

@tacaswell
Copy link
Member

Did you check that the examples this change was introduced to fix are not re-broken?

@dstansby
Copy link
Member Author

I have just checked, and all the examples mentioned in #5757 still work as expected.

@tacaswell tacaswell added this to the 2.0.1 (next bug fix release) milestone Feb 17, 2017
@@ -312,7 +312,8 @@ def __init__(self, bbox1, bbox2, loc1, loc2=None, **kwargs):
raise ValueError("transform should not be set")

kwargs["transform"] = IdentityTransform()
Patch.__init__(self, fill=False, **kwargs)
fill = 'fc' in kwargs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to also check for 'facecolor' and 'color'. Use cbook.normalize_kwargs to sort out the aliases.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't use normalize_kwargs before; something like kwargs = cbook.normalize_kwargs(kwargs, alias_mapping={'fc': ['facecolor', 'color']}) ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See

kwargs = cbook.normalize_kwargs(kwargs, _alias_map)
for an example.

You can use normalize_kwargs to sort out fc vs facecolor, etc . You will have to do the color / facecolor / edgecolor normalization by hand I think.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the example, I should have fixed this now.

@ghost
Copy link

ghost commented Mar 11, 2017

The latest commit should fix the issue if facecolor or color is given (or an alias) but I see a few potential problems.

  1. If you look at the documentation for BboxConnectorPatch you can see fill is also a valid kwarg argument. By always setting fill in the init, if a user actually passed in the fill argument see line 319 it would throw:
    TypeError: __init__() got multiple values for keyword argument 'fill'
    which does not seem like intended behaviour.
    The mark_inset function also suffers from this problem, which should also be able to take fill arguments see docs.

  2. It seems like a bit of a maintenance issue to manually map the aliases on line 316 if they are ever updated or change, this would then break. Instead I would recommend handleing the kwargs like in matplotlib/axes/_axes.py Line 1971 and reference the _patch_alias_map directly (I know it has the _ private identifier but this seems consistent with how this is handled elsewhere in the existing code).

Suggested Fix:
For BboxConnectorPatch I would suggest something like:

from matplotlib.cbook import normalize_kwargs
import matplotlib.patches as Patches
.
.
.
kwargs = normalize_kwargs(kwargs, Patches._patch_alias_map)
if 'fill' in kwargs:
    Patch.__init__(self, **kwargs)
else:
    fill = ('facecolor' in kwargs) or ('color' in kwargs)
    Patch.__init__(self, fill=fill, **kwargs)

AND

For mark_inset something like:

kwargs = normalize_kwargs(kwargs, Patches._patch_alias_map)
if 'fill' in kwargs:
    pp = BboxPatch(rect, **kwargs)
else:
    fill = ('facecolor' in kwargs) or ('color' in kwargs)
    pp = BboxPatch(rect, fill=fill, **kwargs)

That way any valid input should be handled correctly.

@dstansby dstansby self-assigned this Mar 13, 2017
@dstansby
Copy link
Member Author

@Mr-Ian-Ferguson could you put your suggested changes in a new pull request?

@QuLogic QuLogic modified the milestones: 2.0.1 (next bug fix release), 2.0.2 (next bug fix release) May 3, 2017
@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.0.3 (next bug fix release) Jul 11, 2017
@tacaswell
Copy link
Member

@Mr-Ian-Ferguson @dstansby What is the status of this?

@dstansby
Copy link
Member Author

I don't plan to pick this up, but thought I'd leave the PR open for reference.

@tacaswell tacaswell modified the milestones: 2.2 (next next feature release), 2.1 (next point release) Jul 11, 2017
@ghost
Copy link

ghost commented Jul 16, 2017

Sorry I've been without internet for a while. I probably won't be picking this up again, just something I noticed in passing while looking for a different issue. That said I stand by my above suggestions and your welcome to use as you see fit; I just don't have time to do proper testing right now or do a full PR.

@dstansby dstansby removed their assignment Jul 25, 2017
@dstansby
Copy link
Member Author

dstansby commented Nov 2, 2017

I still have no plans to pick this up, so going to close.

@dstansby dstansby closed this Nov 2, 2017
@QuLogic QuLogic modified the milestones: needs sorting, v2.2.0 Feb 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants