On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom <[email protected]> wrote:
> On 06/23/2011 03:49 PM, Benjamin Root wrote:
>
> Hello all,
>
> I am working to make mplot3d feature-parity with regular axes objects. I
> have come across a possible design flaw with the CallbackRegistry.
>
> Many of the Axes3D methods are merely wrappers around Axes methods letting
> it do the work for x and y axis and then let Axes3D do the same for the z
> axis. In Axes.cla(), self.callbacks gets a CallbackRegistry of signals
> named "xlim_changed" and "ylim_changed". However, once that is set, it does
> not appear to be a way for me to add another signal of "zlim_changed" in
> Axes3D.cla(). I could replace self.callbacks with a new CallbackRegistry,
> but since there is a lot of interveaning code between that first
> initialization of self.callbacks and coming back out of Axes.cla(), I worry
> that some callbacks may have been registered by then and would get
> eliminated in the process.
>
> Is there a recommended way around this? Or maybe this is more evidence that
> we should move towards the use of a dictionary of axis objects and make Axes
> functions more agnostic to the number of axis?
>
> I don't know if there is a way around it as the code currently stands. Your
> proposal here:
>
> https://github.com/matplotlib/matplotlib/issues/379
>
> seems like one way out. Then the code that creates the CallbackRegistry in
> Axes.cla() could iterate through all the axes and create a callback type for
> each of them.
>
> However, to step back from this, I've never quite understood why it was
> necessary to have a fixed set of callback types in the CallbackRegistry to
> begin with. It seems to me it comes from a history of callback registry
> classes I've seen in more static languages (such as libsigc++). We could
> just as easily create new signal types on the fly as they are registered.
> You lose some error checking, I suppose, if the caller and receiver don't
> agree on the names, but seems like a small price to pay.
CallbackRegistry.signals is a "public" attribute, so is there anything
preventing you Ben from just doing
self.callbacks.signals.add('zlim_changed')
and then connecting your desired callback?
JDH
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
