The idea to pass the reference of the tool, is just to have a collection of instantiable classes. This allows me to create the toolbar and keymap with their class attributes without instantiating the classes. And leave the __init__ method available for more important things, as window creation and that kind of things. If I don't handle the tool trigger in navigation then I have to check for toggled tools, to untoggle others. And if toggled from keypress then toggle toolbar without calling callback, etc...... Right now this problem doesn't exist because the buttons are not toggle, but I definitively want to use Toggle buttons, I hate that I don't know if zoom is active or not. Why to keep the instances alive? take the example of configuresuplots, in this case if I don't keep the instance alive, I will end with many windows, or having to deal with singletons that I think is not a good idea. Other examples comes to mind, for example if you want to make a logger, you want it to be alive in the background and not being a toggle. Federico On Tue, Jan 28, 2014 at 9:32 PM, Thomas Caswell <tca...@gm...> wrote: > On Tue, Jan 28, 2014 at 7:27 PM, Federico Ariza > <ari...@gm...> wrote: >> activate: I agree with you, renamed to trigger >> >> [I don't understand. The `__init__` gets called when the tool object >> is created (and it gets registered with a particular >> `NavigationBase`/`Figure`/`canvas`. The tool object then sits around >> doing nothing waiting to be triggered. I can see wanting to remove >> one of these buttons, in which case it will need to be un-registered] >> >> I am not expressing myself correctly, what I am trying to say is that >> the Tool object is only created when the tool is triggered. >> The tool.trigger method is called in the ToolBase.__init__ method >> For ToolBase tools, the object is not registered, so there is no >> reference to it anywhere, so it should be garbage collected. I can add >> a del to the object but I think is unnecesary. >> ToolPersistentBase >> [shouldn't `__init__` be called when the tool is created? >> I think the confusion here is that I don't create the tools until they >> are triggered, until then, is just a reference to the class. in the >> navitaion._tools dict. > > If you do not instantiate the object until the button get pushed, why > even bother with a class, can't this just be a function? I still > think it would be better create the `Tool` objects when you create the > figure and then call their `trigger` function when the button gets > pushed. For one thing, this makes it dead-simple to rig up the gui > side of things (at least in Qt, I would assume the others are similar > `button.clicked.connect(self._home_tool.trigger)` ) as the functions > we care about already look like call-backs. I am not sure that the > benefit of doing it the way you wrote it (with the button-push-time > object creation) is worth the added complexity. > > > I think we only need two kinds of tools, the kind you push once and > they fire off an action (simple push button, need one public function > `trigger` this works for simple actions home, quit, back and things > that create extra windows) and the kind you can toggle on and off > (need two public functions `enable` and `disable` which are what they > do when you turn them on (set up call backs to grab input) and turn > them off (tear down/disconnect the canvas call backs) which eliminates > much of the need for keeping track of locks (I think). The toggle > kind may or may not be group in to exclusion groups (pan/zoom) but I > could see doing 'toggle grid lines' as this type as well. > > Tom > > -- > Thomas Caswell > tca...@gm... -- Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? -- Antonio Alducin --