Is there a use-case for a Tool that does not implement it's own trigger? If there is not (and you don't plan to use multiple inheritance) I suggest this raise NotImplemented

Yes there is, if you look at backend_tools.ToolViewsPositions doesn't use a trigger method

ok. sorry for the noise.

I would do everything as properties, rather than stand-alone setters.

I always prefer properties, but in this case, if it is going to be overwritten by the tool creator, it is too easy to forget to add the @figure.setter

Not fully sold on that, it is just as easy to forget to override set_figure.

If you are overriding set_figure you know you want to, but if you are overriding figure it is pretty easy to forget to add @figure.setter specially when you are subclassing an existing tool

what do you think on adding

@figure.setter
def figure(self, figure):
   self.set_figure(figure)

Not a fan of this double function, but solves both of our problems

@OceanWolf Use case. Here I am advancing myself, but for single figure, it is not that useful because you can just do whatever you want to do after __init__, in the case of multiple figure manager (MEP23) that is my ultimate goal, it is very, very, very important.

@tacaswell I usually do the same public/private, but in this case, I was trying to get normal users to be able to play easily and create tools easily. So far, if you want to customize your plot window in any way, it requires a lot of internal code knowledge

@fariza Okay, I will take your word for that, just when you say "set_figure is one of those methods that are prone to be overriden for simple tool creation", yet I don't see any of that here, why this would become a common thing for users to want to do. Could we leave this part of the API until MEP23? Better to later expand the API than to change it.

In the case of MEP23, this is useful when a tool need access to the new and old figure.
For example, connect and disconnect from a canvas event.
If the tool has a window, refresh the content when the figure changes.
Keep track of all the figures

But if you insist, and I agree that for this MEP is not that important,
I will remove it and leave the @figure.setter and we'll deal with that later.

@tacaswell @OceanWolf done. I guess you are right, I am being just stubborn

Why not for the moment set the figure directly in the __init__? Can you see a use-case for changing the figure in the current setup? Atm I only see set_figure getting called by __init__. If the use-case only begins with MEP23 then I suggest adding the set_figure part of the API there.

Not against it, just trying to adhere to the KISS principle 😉., and atm it looks like unneeded complexity.

should this be self._figure, just in case we change our minds about setters later and turn it into a property?