I will resolve the problems with newlines and blankspaces but, the problems with Tests/ Python 3.12, it's not because of something I did right?

Oh ok thank you, I will work on that!

I'm not really sure it's actually a good idea to add bbox support in each artist class one at a time. Instead, it may be more viable to have something like FancyBboxPatch.around_artists(list-of-artists, **kwargs); or at least have bbox support in the base artist class, relying on the generic get_window_extent method to figure out how big to draw the bbox?

Hm ok, i understand your point, but I did what I understood throught my conversation with the developers on the tab of the issue (I did show the API, etc). Maybe I understood wrong. @story645, @rcomer, what do you think it's the best? Do I have to change my aproach?

I'm not really sure it's actually a good idea to add bbox support in each artist class one at a time.

Which artists would it make sense to have a bbox for?

Do I have to change my aproach?

Depends - if a method is added to fancy box then yes, if the implementation is in base artist than you'll move the solution into the artist class but you still need to propose the arguments and show examples.

attn @timhoffm

Hm ok, i understand your point, but I did what I understood throught my conversation with the developers on the tab of the issue (I did show the API, etc).

Please understand that not all developers read all discussions at the same time nor do we all necessarily agree immediately on the best way to implement a feature (or whether we even want it to be added). It is not so rare to have multiple rounds of back and forth between the API-design side and the actual implementation work.

Which artists would it make sense to have a bbox for?

A more general reason why I raised this point is that the current implementation seems to be very tied down to QuiverKey implementation details, but a more generic one (based on get_window_extent) may be possible.

I have not followed all the details here, but currently QuiverKey does not have a get_window_extent method. I think that in order to implement one, you would need most of the logic currently in _draw_bbox. So, regardless of what the final implementation is, it might be a good idea to factor that out. This would have the added bonus of closing #18530.

Please understand that not all developers read all discussions at the same time nor do we all necessarily agree immediately on the best way to implement a feature (or whether we even want it to be added). It is not so rare to have multiple rounds of back and forth between the API-design side and the actual implementation work.

Yes, that makes sense, I'm still new at this.

So @story645, @rcomer, in summary, what do you want me to do? I understood your points and views, but I'm unsure what the final decision is.

I don't think anyone wants you to do anything. Again, the tricky part is figuring out what to do, not so much how to do it.

@story645, @rcomer, in summary, what do you want me to do?

Like @anntzer said, we've gotta come to consensus for quiverbox. I think for now, you can work on @rcomer 's suggestion of creating a get_window_extent method. That will close an outstanding issue, and if consensus ends up being to generalize the solution than having written the specific solution will help you write the general form.

Yes, I know, I was talking about the part of being more generic. Ok, thank you, @story645 .