Re: [matplotlib-devel] FYI: SVG with option "svgfont" enabled hangs inkscape

2011-06-23 Thread Michael Droettboom 
Yep.  That's the reason that's not the default setting.  The docs for 
svg.fonttype says:

#svg.fonttype : 'path' # How to handle SVG fonts:
#'none': Assume fonts are installed on the machine where the SVG 
will be viewed.
#'path': Embed characters as paths -- supported by most SVG renderers
#'svgfont': Embed characters as SVG fonts -- supported only by Chrome,
#   Opera and Safari

Mike

On 06/22/2011 03:56 PM, Dieter Weber wrote:
> Hi,
> it's not directly a problem with matplotlib, but I just wanted to let
> you know that SVGs generated with
>
> matplotlib.rcParams['svg.fonttype'] = 'svgfont'
>
> hang inkscape.
>
> Greetings,
> Dieter
>
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] adding valid signals to a CallbackRegistry?

2011-06-23 Thread Benjamin Root 
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?

Thanks,
Ben Root
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] adding valid signals to a CallbackRegistry?

2011-06-23 Thread Michael Droettboom 

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.


Mike

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] adding valid signals to a CallbackRegistry?

2011-06-23 Thread John Hunter 
On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom  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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] adding valid signals to a CallbackRegistry?

2011-06-23 Thread Eric Firing 
On 06/23/2011 10:53 AM, John Hunter wrote:
> On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom  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?

Yes, it requires some modification to the CallbackRegistry:

 def __init__(self, signals):
 '*signals* is a sequence of valid signals'
 self.signals = set(signals)
 self.callbacks = dict([(s, dict()) for s in signals])
 self._cid = 0

So adding to the set of signals is not enough.  It would be easy to made 
an add_signal() method to take care of the two necessary steps.  It 
would seem simpler, however, to just let the signals be added 
automatically as needed, as I believe Mike is suggesting.

Actually, it looks like self.signals could be replaced by a property 
that, upon reading, would return self.callbacks.keys().  Why use two 
data structures if one will do?  Of course, since signals is public, 
that would represent API breakage--but of a rather obscure sort.

(Shooting from the hip; I haven't looked closely.)

Eric

>
> 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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] adding valid signals to a CallbackRegistry?

2011-06-23 Thread Benjamin Root 
On Thu, Jun 23, 2011 at 4:29 PM, Eric Firing  wrote:

> On 06/23/2011 10:53 AM, John Hunter wrote:
> > On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom
>  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?
>
> Yes, it requires some modification to the CallbackRegistry:
>
> def __init__(self, signals):
> '*signals* is a sequence of valid signals'
> self.signals = set(signals)
> self.callbacks = dict([(s, dict()) for s in signals])
> self._cid = 0
>
> So adding to the set of signals is not enough.  It would be easy to made
> an add_signal() method to take care of the two necessary steps.  It
> would seem simpler, however, to just let the signals be added
> automatically as needed, as I believe Mike is suggesting.
>
> Actually, it looks like self.signals could be replaced by a property
> that, upon reading, would return self.callbacks.keys().  Why use two
> data structures if one will do?  Of course, since signals is public,
> that would represent API breakage--but of a rather obscure sort.
>
> (Shooting from the hip; I haven't looked closely.)
>
> Eric
>
>
I am willing to go with whatever makes everyone happy.  I have a limited
amount of time, and my goal with the feature-parity branch (found here:
https://github.com/WeatherGod/matplotlib/tree/mplot3d/consistency ) is to
get a z-version of every single axis-related function into Axes3D, and make
sure that most other functions that operate on arbitrary axis are capable of
acting on the z-axis.

However, I do not intend to make sure that everything works (only that there
are no regressions).  For example, setting axis label properties ('right',
'left', etc.) make little sense in the current context, and working with
minor ticks do nothing in mplot3d.  The idea is that if the added functions
work, then that is good news.  If the added functions do not work, then that
can be a bug report.

Therefore, anything that gets me to that goal would be fine.  Heck, doing
nothing about this might also work because there never was a callback for
zlim_changed before, so not having it now will be no loss of function.

Sorry for rambling,
Ben Root
--
All the data continuously generated in your IT infrastructure contains a 
definitive record of customers, application performance, security 
threats, fraudulent activity and more. Splunk takes this data and makes 
sense of it. Business sense. IT sense. Common sense.. 
http://p.sf.net/sfu/splunk-d2d-c1___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-dev