matplotlib-devel Mailing List for matplotlib

Thanks for bringing this back onto the mailing list.
I am excited for the prospect of new algorithms for contouring. My company
has actually been using the contourf() function for the past few years to
generate the polygons from gridded data to then make shapefiles from those
polygons. Having an rcParam and a kwarg for controlling which algorithm
gets used for contouring would be good for us when we transition to any new
algorithms.
I also advocate strongly for better separation between the plotting and the
contouring. I made an attempt awhile back for my work to not have to call
contourf() so that my shapefile library code wouldn't interfere with
anybody's plotting that they happen to be doing, but I just couldn't get a
clean separation. I ended up having to wrap my contouring code as a
sub-process.
Do keep me in the loop about this, as I have a fairly substantial data
source for testing.
Cheers!
Ben Root
On Fri, Jan 31, 2014 at 2:51 PM, Eric Firing <ef...@ha...> wrote:
> On 2014年01月30日 10:22 PM, Ian Thomas wrote:
>
> > (Taking this away from the mailing list as it is going off topic).
>
> I'm putting it on the devel list; it will be good for others to know
> this is in the works, and be able to advise on strategy before it gets
> to the PR stage.
>
> >
> > The new contour code can do both the old blocky form of contouring and
> > the new corner-cutting. As you suggest, I was going to leave the old
> > algorithm in mpl as well (perhaps undocumented), so there will be three
> > choices for contouring in the short term, eventually reduced to two when
> > we can safely remove the old algorithm. I was going to opt for a kwarg
> > to contour(f) to specify which of the three algorithms, as this will
> > allow easy automated testing and a comparison example that shows the
> > blocky and corner-cutting results side-by-side. I like the idea of an
> > rcParam though, which could be used as a default if the kwarg is not
> > specified in a particular contour(f) call. Does this sound like a good
> > plan?
>
> Yes, I think this is ideal.
>
> Would the new code be substantially simpler if the blocky capability
> were omitted from it? If so, then it seems like it would makes sense to
> leave the blocky form to the old code.
>
> >
> > By the way, the reason it is yet again slow to progress is that I've had
> > to do a partial rewrite. If you remember I had taken the approach of
> > using a single large numpy array of points per pair of contourf levels
> > that was really fast for the contouring algorithm to produce but
> > potentially slow for rendering and would eventually hit some backend
> > limit of max number of points rendered at any one time. Well now I've
> > reverted to the same output as the old algorithm, i.e. a numpy array for
> > each polygon and its contained holes, which is obviously much safer. It
> > turned out that my naive changes to do this scaled really badly so I had
> > to rewrite some of the algorithm to calculate the hole containment as it
> > progresses. Because of this It is much less elegant than it was and I
> > need to put in a bit more time to make it easier to understand before
> > release.
>
> Less elegant--too bad!
>
> One thing to keep in mind is the desire for a cleaner separation between
> the generation of the contours and their plotting. Sometimes one
> actually wants the polygons themselves; for example, topographic
> contours can be used to define boundaries for internal wave flux
> calculations. A student here at UH is doing exactly this.
>
> Eric
> >
> > Ian
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 2014年01月30日 10:22 PM, Ian Thomas wrote:
> (Taking this away from the mailing list as it is going off topic).
I'm putting it on the devel list; it will be good for others to know 
this is in the works, and be able to advise on strategy before it gets 
to the PR stage.
>
> The new contour code can do both the old blocky form of contouring and
> the new corner-cutting. As you suggest, I was going to leave the old
> algorithm in mpl as well (perhaps undocumented), so there will be three
> choices for contouring in the short term, eventually reduced to two when
> we can safely remove the old algorithm. I was going to opt for a kwarg
> to contour(f) to specify which of the three algorithms, as this will
> allow easy automated testing and a comparison example that shows the
> blocky and corner-cutting results side-by-side. I like the idea of an
> rcParam though, which could be used as a default if the kwarg is not
> specified in a particular contour(f) call. Does this sound like a good
> plan?
Yes, I think this is ideal.
Would the new code be substantially simpler if the blocky capability 
were omitted from it? If so, then it seems like it would makes sense to 
leave the blocky form to the old code.
>
> By the way, the reason it is yet again slow to progress is that I've had
> to do a partial rewrite. If you remember I had taken the approach of
> using a single large numpy array of points per pair of contourf levels
> that was really fast for the contouring algorithm to produce but
> potentially slow for rendering and would eventually hit some backend
> limit of max number of points rendered at any one time. Well now I've
> reverted to the same output as the old algorithm, i.e. a numpy array for
> each polygon and its contained holes, which is obviously much safer. It
> turned out that my naive changes to do this scaled really badly so I had
> to rewrite some of the algorithm to calculate the hole containment as it
> progresses. Because of this It is much less elegant than it was and I
> need to put in a bit more time to make it easier to understand before
> release.
Less elegant--too bad!
One thing to keep in mind is the desire for a cleaner separation between 
the generation of the contours and their plotting. Sometimes one 
actually wants the polygons themselves; for example, topographic 
contours can be used to define boundaries for internal wave flux 
calculations. A student here at UH is doing exactly this.
Eric
>
> Ian

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

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

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

Hi Nathan,
To deal with your immediate problem of not wanting to see the deprecation
warnings you can continue to use matplotlib.delaunay and suppress the
warnings using e.g.
http://docs.python.org/2/library/warnings.html#temporarily-suppressing-warnings.
This will be OK for a year or two, but eventually we will completely remove
matplotlib.delaunay. It will however give you time to come up with a
solution.
The short answer is
1) replace all use of matplotlib.delaunay.Triangulation with
matplotlib.tri.Triangulation, and
2) use some other form of interpolation than natural neighbour!
Matplotlib has linear and cubic triangular grid interpolators (
http://matplotlib.org/dev/api/tri_api.html); if these are acceptable your
code changes should be minimal. scipy.interpolate has a few more options
(but no natural neighbour) which will be a little more work. Even if you
were to like the natgrid approach I would steer you away from it as I can
see us removing it completely from matplotlib sometime in the future.
Alternatively you could incorporate the matplotlib.delaunay code into your
project and hence carry on using it as you are, but this would be madness
as you would have to deal with the building of a C python extension, plus
the delaunay code is 'not very robust'. You will no doubt have observed
this to be the case, and it is the reason why matplotlib and scipy have
moved away from it to use qhull instead.
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 hope this has been of some help, but I fear not...
Ian Thomas

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

Hi all,
I'm writing regarding an issue I'm having porting the yt package to
properly handle some of the changes in matplotlib 1.4.
yt is a python library for analysis and visualization of volumetric
data, with a focus on astrophysical simulation datasets. We use
matplotlib heavily for visualization tasks.
For a while now, we've been using the natural neighbor interpolation
in matplotlib.delaunay to generate contour plots from image data. See
for example, this function:
https://bitbucket.org/yt_analysis/yt/src/84b551a47ac462d646963f0b13e4dd0e85bd9751/yt/visualization/plot_modifications.py?at=yt#cl-311
In this example, self.triang is an instance of
matplotlib.delaunay.triangulate.Triangulation.
The bug report I opened regarding this issue might also be informative:
https://bitbucket.org/yt_analysis/yt/issue/764/matplotlibdelaunay-deprecated-in
I'm writing because it seems that matplotlib.delaunay was deprecated
recently. This means users who import the yt plotting code will see a
DeprecationWarning if they are running the upcoming matplotlib 1.4
release -- definitely an undesirable situation.
Unfortunately, it looks like the workaround for this issue is to use
natgrid to generate the interpolation. This is undesirable from our
point of view since we have no way in general to control how users build their
matplotlib installation.
I'm curious whether any of the matplotlib developers have alternate
ideas for how to do deal with this.
Thanks for your help!
-Nathan Goldbaum

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

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
>

Looks like there could be some white space around that block, as you say. (
https://raw.github.com/matplotlib/matplotlib/master/doc/contents.rst and
https://github.com/matplotlib/matplotlib/blob/master/doc/contents.rst).
Have you ever built the mpl docs? Are you interested in trying to fix this
and submitting a PR? I'd happily review and merge in time for the v1.4
release.
Phil
On 8 January 2014 09:21, Pierre Haessig <pie...@cr...> wrote:
> Hi,
>
> On the main doc page http://matplotlib.org/contents.html the "Examples"
> section is misaligned (because it gets surrounded by a blockquote tag).
> I guess it relates to the special treatment it gets in content.rst
> (https://raw2.github.com/matplotlib/matplotlib/master/doc/contents.rst).
> I don't know what magic is required to put it right (I always make
> alignment errors myself with Sphinx...). Maybe just add or remove one
> space ?
>
> best,
> Pierre
>
> (beyond this alignment issue, I feel like this small Examples link is a
> bit lost. It may deserve a stronger visual presence)
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Sadly I wont be - it is a bit of a long way for a non-scientific
conference. Hoping to be able to attend SciPy again this year - there was a
strong mpl contingent and we had some really successful introductory
sprints held.
Cheers,
On 10 January 2014 14:49, Federico Ariza <ari...@gm...> wrote:
> Hello everybody
>
> Is anybody going to pycon 2014 in Montreal.
> Is there a sprint planned for that conference?
>
> Thanks
> 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
>

I've only just seen this, but thanks for sharing! The blog post was well
thought out and very interesting.
I really liked the "latest" style idea - I think that is something that
gives us a bit of flexibility to change our minds about styles and continue
to keep everybody moving forward with enhanced output. Out of interest,
have you submitted your style to mpl master? I haven't seen anything go by,
and can't see any reason why it can't be included in master, even if it
isn't enabled by default. Essentially, I think Tony Yu et al.'s good work
needs to be stretched in this way to ensure we are making the most of the
new functionality, so please do submit PRs if there is something that can
be improved!
Cheers,
On 13 January 2014 19:58, Chris Beaumont <bea...@ha...> wrote:
> Hi Everyone,
>
> I found some time to look at the votes from the "Plot or Not?" experiment
> Adrian Price-Whelan and I ran during SciPy last summer. You can take a look
> at my summary at
> http://datarazzi.wordpress.com/2014/01/13/plot-or-not-voting-results/, or
> explore for yourself at http://plotornot.chrisbeaumont.org .
>
> Plot or Not was mostly a tongue-in-cheek idea, but there is nonetheless
> some interesting information about style preferences in these data. I'm
> happy to share the raw vote data if anyone is interested in digging further.
>
> Cheers,
> Chris Beaumont
>
>
> ------------------------------------------------------------------------------
> 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
>
>

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

matplotlib is not able to use .otf format fonts. We bundle a version 
where they have been converted to .ttf. We could update our code to use 
.otf fonts but it's considerable work, involving writing code on top of 
freetype to convert and subset our fonts, rather than the 15-year-old 
ttconv code we use now.
Mike
On 01/23/2014 06:00 PM, Paulo César Pereira de Andrade wrote:
> Hi,
>
> I asked for a bundling exception in Fedora, see
>
> https://fedorahosted.org/fpc/ticket/381
>
> But I should only be able to get a temporary one,
> and that based on any feedback I receive here :-)
>
> Problem is, matplotlib bundles stix fonts 1.0, and
> fedora, since fedora 18 ships stix fonts 1.1, that are
> not "really" compatible with 1.0.
>
> I got things working for Fedora 18 by using
> "USE_FONTCONFIG = True", but, every other distro,
> probably sans Fedora spins bundles fonts and does
> not use fontconfig.
>
> From fedora 18 to 20 several updates were made to
> fix side effects of using fontconfig, then, ultimately,
> fedora 20 was shipped with my patch to use fontconfig
> removed, because the patch was (apparently) upstreamed
> 95% workarounds to side effects of using fontconfig, but
> the change to use fontconfig removed by mistake... So,
> there is also a kind of chicken and egg problem, no
> bundling policy, and no patching (or as few as possible and
> with a good reason) policy.
>
> I would like to have any suggestion of a very good
> reason to bundle stix fonts, or, some idea of how to
> handle it, if matplotlib cannot use fontconfig by default
> on Linux and *BSD.
>
> Thanks,
> Paulo
>
> ------------------------------------------------------------------------------
> 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
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

I want to apologies because, as some of you noted, I sent some e-mails to this 
list in which they were not destined for. It was a bad configuration of my mail 
client that I just corrected now so I hope it won't happen again.
Please, sorry for the inconvenience.
-- 
Philippe Mallet-Ladeira
CEMES, UPR-8011 CNRS
Groupe NanoMat Tél.: +33 [0]5 62 25 79 38
BP 94347 (29 Rue Jeanne Marvig) E-mail : phi...@ce...
F-31055 Toulouse Cedex 4 
France

 Hi,
 I asked for a bundling exception in Fedora, see
https://fedorahosted.org/fpc/ticket/381
 But I should only be able to get a temporary one,
and that based on any feedback I receive here :-)
 Problem is, matplotlib bundles stix fonts 1.0, and
fedora, since fedora 18 ships stix fonts 1.1, that are
not "really" compatible with 1.0.
 I got things working for Fedora 18 by using
"USE_FONTCONFIG = True", but, every other distro,
probably sans Fedora spins bundles fonts and does
not use fontconfig.
 From fedora 18 to 20 several updates were made to
fix side effects of using fontconfig, then, ultimately,
fedora 20 was shipped with my patch to use fontconfig
removed, because the patch was (apparently) upstreamed
95% workarounds to side effects of using fontconfig, but
the change to use fontconfig removed by mistake... So,
there is also a kind of chicken and egg problem, no
bundling policy, and no patching (or as few as possible and
with a good reason) policy.
 I would like to have any suggestion of a very good
reason to bundle stix fonts, or, some idea of how to
handle it, if matplotlib cannot use fontconfig by default
on Linux and *BSD.
Thanks,
Paulo

Hello
What if instead of removing the NavigationToolbar stuff, we add a
rcParams['navigation'] to signal the use of the new classes insted of
the old ones?
This way we can add deprecation warnings to the old classes to smooth
the transition.
Personally I don't like the idea, this adds too many if/else patches.
Federico
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --

Hello everybody
I just updated the implmentation part of
https://github.com/matplotlib/matplotlib/wiki/Mep22 to reflect what is
already in place, should be clearer than navigate through the code
The example should be working examples/navigation.py
I know it is confusing, and there are better ways to do many of the
things that I try to do.
Please ask questions, make comments and give your opinion.
For the time being I only implented the changes in GTK3, but if I see
that you are happy with the shape this is going, I will do it for the
other backends (where I know how to do it) and will ask for help
(where I don't know how to do it)
Thanks
Federico
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --

Le mardi 21 janvier 2014 12:27:58 Nicolas Ratel-Ramond a écrit :
> Salut Philippe,
> 
> Pourrais-tu m'écrire noir sur blanc les infos que tu recherches dans les
> fichiers TOPAS, afin que j'en fasse la demande auprès de mon collégue du
> CIRIMAT?
> En te remerciant,
> Nicolas
Salut Nicolas,
alors, je veux l’aire des pics qui composent la raie 10 / 100. Il y en a 
plusieurs normalement.
Mais s’il s’agit de faire un copier-coller, peut-être qu’il est possible de 
copier tous les paramètres de tous les pics?
-- 
Philippe Mallet-Ladeira
CEMES, UPR-8011 CNRS
Groupe NanoMat Tél.: +33 [0]5 62 25 79 38
BP 94347 (29 Rue Jeanne Marvig) E-mail : phi...@ce...
F-31055 Toulouse Cedex 4 
France

I've implemented a new feature called shade_color which will either
brighten or darken a color based on a certain percentage. Compare URL is
here:
https://github.com/dvreed77/matplotlib/compare/master...shade_color