matplotlib-devel Mailing List for matplotlib

@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
<ari...@gm...> 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 <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 --
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --

On Tue, Jan 28, 2014 at 12:59 AM, Ian Thomas <ian...@gm...> wrote:
> I expect we will add more triangular grid interpolators to matplotlib in
> due course and I am happy to receive suggestions on this. However, this
> will not include natural neighbour. Natural neighbour interpolation is
> specific to delaunay triangulation, and as we also support user-specified
> triangulations I am only interested in interpolation that covers all
> triangulations.
>
I appreciate the separation of the triangulation from the interpolation,
but I also like natural neighbor.
But is it really only usable with delauney triangulations I can see that
it may not have very nice properties when applied with a very
non-delaunay triangulation, but I can't see why it it wouldn't be
computable. Or am I missing something?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

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 --

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...

@tacaswell regarding your last comments on the wiki
Again, please let me know if something is not clear or you have suggestions
Again, sorry for the long email, but please don't forget the previous
one about the locks.....
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.
ToolToggleBase
[I would give them enable/disable methods, and make their `triggered`
action to call their own `enable`]
Actually it makes more sense, thanks.
On Tue, Jan 28, 2014 at 6:17 PM, Federico Ariza
<ari...@gm...> wrote:
> Hello again
>
> I have been playing with the locks to find a solution.
> What we need is a way to let tools absorb the events (lock its use).
>
> The problem that I'm facing is that Navigation itself needs to capture
> two different events.
>
> key_press_event for tool triggering
> motion_notify_event for setting the message with the pointer position
> and cursor changing.
>
> Now the options that I see are:
>
> Let the tools disconnect and reconnect this signals in navigation.
> self.figure.canvas.mpl_disconnect(self.navigation.id_move)
> ....
> self.navigation.id_move =
> self.figure.canvas.mpl_connect('motion_notify_event',
> self.navigation.mouse_move)
>
> Create helper methods to disconnect and reconnect this signals in navigation
> self.navigation.disconnect('mouse_move')
> ....
> self.navigation.connect('mouse_move')
>
> Use locks and let navigation redirect these events to the appropiate
> place (what I'm doing right now).
> self.navigation.movelock(self)
> self.navigation.movelock.release(self)
>
> Do you see other options?
>
> One thing that is clear, is that for the moment Navigation needs only
> two handlers, so I can reduce the number of locks to two....
>
> Thanks
> Federico
>
> On Tue, Jan 28, 2014 at 11:05 AM, Federico Ariza
> <ari...@gm...> wrote:
>> @tacaswell I modified the wiki reflecting the changes and trying to
>> answer the questions.
>> Please let me know if I answered your questions/concerns. We can
>> iterate as muchs as needed on this, I have no problem modifying the
>> names or functionnality.
>>
>> Sorry for the long email
>> Here a list of things that I changed
>>
>> ToolBase
>> description = '': Small description of the tool
>>
>> persistent = False: If True, the instance of the Tool is registered
>> with Navigation for reuse.
>> This is needed because some tools are keept alive in the background,
>> for example SubplotTool.
>>
>> position = None: Where is it positionned in the toolbar?. -1 = at the
>> end, None = Not in the toolbar.
>> The default tools are all ordered by their position in the Navigation
>> _default_tools array. This argument is mainly used by User created
>> tools that are added after the Toolbar creation.
>> My idea was that for the user created tools, the user could set the
>> position without having to subclass the Navigation class.
>> So this information has to be included in the Tool.
>>
>>
>> activate(self, event): This is the main method of the Tool, it is
>> called when the Tool is triggered by:
>> * Toolbar button click
>> * keypress associated with the Tool Keymap
>> * Call to navigation.click_tool(name)
>>
>>
>> ToolPersistentBase
>> unregister(self, *args): ... Because ToolBase is intened for single
>> use, there is no need of registration for the instances, persistent
>> tools, need to be registered so __init__ is called only onece during
>> the first trigger
>>
>>
>> NavigationBase
>> locks.... I tend to agree with you.
>> The idea that I had in mind, and maybe was more complex than expected.
>> Was to redirect the events to the tool without need to call the
>> mpl_connect within the tool. So I provided the methods to handle those
>> events directly.
>> This is also from the idea that if we implement the
>> MultiFigureManager, when there is a change on the 'active_figure'
>> Navigation knows about the change and changes the event handlers, in
>> this case the Tools don't need to do anything.
>> It was just to simplify the Tool creation eliminating the need for
>> basic event connection in case of figure changes.
>>
>> Even if we remove the locks we need two locks:
>> canvaslock (for the input)
>> keypress lock, to give the tool the option to absorb the keypress
>> completely. (Tool for anotations comes to mind)
>>
>> I didn't remove the comment for the locks, because I am not sure what
>> is the best option.
>>
>>
>> ToolbarBase
>> I tried to clarify the use of the methods. Most of the methods that
>> you mentionned, are for internal use only but are mandatory for
>> backend implementation.
>> Also I updated the wiki with the "_" that was missing from the private methods.
>>
>> On Mon, Jan 27, 2014 at 9:12 PM, Thomas A Caswell <tca...@uc...> wrote:
>>> I left some comments on the wiki (in []). Not sure what the best way
>>> to leave comments is.
>>>
>>> On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza
>>> <ari...@gm...> wrote:
>>>> Hello everybody
>>>>
>>>> I just added "click_tool" to simulate a click programatically.
>>>> https://github.com/matplotlib/matplotlib/pull/2759
>>>>
>>>> Is there anything missing or that you want to change?
>>>> I'm saturated so I don't see anything anymore.
>>>>
>>>> I would like to have some input specially in the `ToolbarBase` class.
>>>> I am ready to start the implementation on the other backends, and this
>>>> is the "new class" that have to be implemented for all the backends.
>>>> `Navigation` is mostly copy paste from existing toolbar
>>>>
>>>> Thanks
>>>> Federico
>>>>
>>>> On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pel...@gm...> wrote:
>>>>> Hi Federico,
>>>>>
>>>>> I just wanted to say that I've been a little busy lately, but your MEP is
>>>>> really shaping up - I really like the concepts that are being proposed and
>>>>> think it will make a huge difference to people who want to implement custom
>>>>> UIs.
>>>>>
>>>>> Keep up the great work, and continue trying to get feedback from all of us
>>>>> on this!
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>> On 24 January 2014 18:43, Federico Ariza <ari...@gm...> wrote:
>>>>>>
>>>>>> Hello everybody
>>>>>>
>>>>>> I just added some documentation for the MEP22 new classes and methods.
>>>>>> Please take a look https://github.com/matplotlib/matplotlib/pull/2759
>>>>>>
>>>>>> I ran into some problems, when trying to decide if some methods where
>>>>>> public or not.
>>>>>>
>>>>>> If the method was used only for backend implementation pourposes I put
>>>>>> it as private (name starts with underscore) but still documented them
>>>>>> in the Notes section of the class.
>>>>>> I don't know if this is the correct way to do it, but I couldn't decide.
>>>>>> If you prefer any other way to do it, please let me know.
>>>>>>
>>>>>> Thank you
>>>>>> Federico
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>>>>
>>>>>> -- Antonio Alducin --
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>>>>> Critical Workloads, Development Environments & Everything In Between.
>>>>>> Get a Quote or Start a Free Trial Today.
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Matplotlib-devel mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>>
>>>> -- Antonio Alducin --
>>>>
>>>> ------------------------------------------------------------------------------
>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>>> Critical Workloads, Development Environments & Everything In Between.
>>>> Get a Quote or Start a Free Trial Today.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>>
>>> --
>>> Thomas A Caswell
>>> PhD Candidate University of Chicago
>>> Nagel and Gardel labs
>>> tca...@uc...
>>> jfi.uchicago.edu/~tcaswell
>>> o: 773.702.7204
>>
>>
>>
>> --
>> 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 --
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --