Resolves different edgecolor and hatch color in bar plot

[Vashesh08]

PR summary

Fixes #26074
Continued From #26683

PR checklist

• "closes #0000" is in the body of the PR description to link the related issue
• new and changed code is tested
• Plotting related features are demonstrated in an example
• New Features and API Changes are noted with a directive and release note
• Documentation complies with general and docstring guidelines

[story645]

Hi, thanks for following up. I'm not sure if your tests are in draft form, but they're currently not testing anything because your reference and actual figures are using the same code to make the same image. You may need a mix of comparison and equals_tests here https://matplotlib.org/devdocs/devel/testing.html#writing-an-image-comparison-test

[melissawm]

Hi @Vashesh08 , it looks like you pulled in a number of unrelated commits into your branch. You will probably need to rebase your branch to leave only your commits. If you run into trouble and need help, let us know.

[Vashesh08]

@melissawm I think I removed the unrelated commits. Thanks for the docs!

[story645]

Hi,
I'm really sorry I dropped the ball on finishing this up. If you've got the time, my major question/concern/thing I should have flagged earlier (sorry :wince:) is that the hatchcolor shouldn't be set inside edgecolor. I think seperating it out so that hatchcolor is only set inside set_hatchcolor, even when set to the edge color, should clean up some of the logic chains happening now and will hopefully get rid of the need for a second set_hatch_color variable.

[Vashesh08]

I'm extremely sorry for the delay in responding. I missed out on your response.

The primary concern I had was how should I tackle the hatchcolor when both hatchcolor and edgecolor values both are specified. Since these values are updating using _internal_update method, which makes the order of these parameters important. In order to tackle this, I had to introduced a class variable self.set_hatch_color and local function variables set_hatchcolor_from_edgecolor.

the hatchcolor shouldn't be set inside edgecolor
I think the way this would have to be done would be passing an additional parameter to set_hatchcolor function. Although that would make a redundant variable but I think it would clean up the logic.

I will be pushing these changes. Lmk if you still think there are room for any more improvements.

[story645]

I might be missing something, but I don't see why this isn't just a fallback chain. Also sorry it took so long to get back to you.

[story645]

hi, we discussed this on the call this week b/c I was worried and @ksunden and @QuLogic both suggested that there's a way to inherit the rcparam from edgecolor so that you can reduce the fallback logic and that legend.facecolor already tracks legend.edgecolor and you can maybe use that as a model. What that means is it solves the black default or intentional problem so

• setting hatch.color to 'inherit'

  • needs an API behavior note probably
  • https://github.com/matplotlib/matplotlib/blob/main/lib/matplotlib/mpl-data/matplotlibrc#L534

  • matplotlib/lib/matplotlib/rcsetup.py

    Line 1175 in 5e34777

    "legend.facecolor": validate_color_or_inherit,

• use legend.facecolor tracking legend.edgecolor as model:

  • matplotlib/lib/matplotlib/legend.py

    Lines 532 to 538 in 5e34777

    	facecolor = mpl._val_or_rc(facecolor, "legend.facecolor")
    	if facecolor == 'inherit':
    	facecolor = mpl.rcParams["axes.facecolor"]
    	edgecolor = mpl._val_or_rc(edgecolor, "legend.edgecolor")
    	if edgecolor == 'inherit':
    	edgecolor = mpl.rcParams["axes.edgecolor"]

• include hatches in set_alpha color changes b/c setting alpha after setting edgecolor will overwrite current,

  • needs an API behavior note

• Check for parallel behavior, if possible, between Patch and Collection since both have hatches.

Also thanks for your patience and perseverance on this.

[Impaler343]

@Vashesh08 are you coming back to this? Or should I give it a go

[Vashesh08]

@Impaler343
I have been a little busy and haven't had enough time to work on this. Please go ahead.