@tacaswell I have been thinking about what we discussed last time. Again, sorry for the long email
Locks: I reduced the number of locks to 2. This is what navigation actually uses,: * keypress: to know if it can process the keypress * message: to know if it can print stuff to the message area. Radio/toggling logic inside GUI toolkit: We can put it inside the toolbar because the toolkit already have the mechanics (as you mentionned), The problem is that we have to replicate all this logic inside the navigation in case there is no toolbar. And we have to make sure the two are in sync all the time. Think of sequence, click to trigger tool1, keypress to trigger tool2.... According to me, it becomes messy to know exactly what is going to happen in the toolbar. Radio/toggling logic inside the tools: This can be done, but I don't like the idea of the tools knowing about the other tools, all the tools of the same group have to be registered with the other tools, and adding and removing them at runtime can become messy, if navigation keeps a central register of all the tools, it can make changes without a problem. If a tool wants to know about other tools, they can acces them throught self.navigation. Use tool instances instead of tool clases For this one I am almost on your side. The only downside that I see with this, is: To make GUI tools, it becomes a little bit more work. The tool has to keep track of the window state (open/close) and recreate its gui if it has been closed/destroyed etc.. If we instantiate at first trigger time (as it is right now), the tool can be a standard GUI window with a trigger method, and calling unregister at destroy. No open/close state. Federico On Tue, Jan 28, 2014 at 9:51 PM, Federico Ariza <ariza.feder...@gmail.com> wrote: > 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 <tcasw...@gmail.com> wrote: >> On Tue, Jan 28, 2014 at 7:27 PM, Federico Ariza >> <ariza.feder...@gmail.com> 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 >> tcasw...@gmail.com > > > > -- > Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? > > -- Antonio Alducin -- -- Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? -- Antonio Alducin -- ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
