matplotlib-devel Mailing List for matplotlib

On 07/29/2012 11:33 AM, Dimitrios Apostolou wrote:
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> I didn't add this signature! Either Sourceforge is advertising through
> email now too, or my MUA has a virus...
>
For better or worse, Sourceforge has been doing this for some time.

Mike

On Sat, 28 Jul 2012, Dimitrios Apostolou wrote:

> Even though some things needed time-consuming hacks, matplotlib worked
> fine. Thanks for your work on this fantastic library!  And if you are
> curious you can see my automatic generated graphs (temporarily) at:
>
> http://teras-ics.mooo.com:8003

Sorry but my primary PC died last night, this page will be unavailable for 
some time. :-(


> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

I didn't add this signature! Either Sourceforge is advertising through 
email now too, or my MUA has a virus...


Dimitris

Collin,

My problem is not with the actual "resize" functionality, which works fine,
but with attaching a callback to a resize_event ("say_hello" in my example).
Specifically, I have a figure that uses blitting, i.e., saves the background
and only updates some artists as a function of events in another figure.
Obviously, when the user resizes the blitting figure, the background changes
and the snapshot image has to be regenerated. Hence my need to attach a
callback to a resize event. This works fine in other backends that support
blitting, but not in Qt4Agg.

The reason why it doesn't work lies in
lib/matplotlib/backends/backend_qt4.py, where the last line is missing in: 

def resizeEvent( self, event ):
    ...
    FigureCanvasBase.resize_event(self) 

I was hoping that someone could confirm that this is a bug and that adding
the line is the correct fix for the problem. I was then going to file a bug
report.

Thanks,
Stefan

-- 
View this message in context: http://old.nabble.com/Matplotlib-Qt4Agg-backend-ignores-%27resize_event%27-tp34205981p34226500.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hello list,

I was trying to create some interactive SVGs with matplotlib and I faced 
the following issues. Some maybe bugs, some other just missing 
functionality. I'm just summarising my experience so that you are aware of 
the issues.

First of all I used git-head from a couple of monts ago with python-3.2, 
and I'm quite happy that it worked. :-) My target was to make the dots in 
a plot(x,y,"-o") graph clickable. Here are the issues I faced:

* I didn't find a way to set an "id" attribute for each marker. Googling
   revealed that I should probably call set_gid() but I had no success. So
   I stored the whole XML file into memory and searched for the <use> tags
   inside <g id="line2d_1">. The ideal would have been for each <use> to
   have a specific id, or at least the <g> containing the <use>s.

* pylab.savefig(f, format="svg") never worked whenever f was sys.stdout or
   io.StringIO. It seems that it err'ed on every file that didn't support
   open(). My workaround was to write to a tempfile and read back. Maybe
   support for this can be added together with support for already opened
   files, so that the with-statement works? I /think/ errors were like
   the following:

File "~/dist/src/matplotlib-git/matplotlib/build/lib.linux-i686-3.2/matplotlib/backends/backend_svg.py", 
line 1101, in print_svg
     return self._print_svg(filename, svgwriter, fh_to_close, **kwargs) 
UnboundLocalError: local variable 'svgwriter' referenced before assignment

* I couldn't use pylab.ticklabel_format() with SVG engine (I was trying to
   apply an offset to the xticks labels), error message was the following,
   it's quite probable I don't understand how this works:

File "~/dist/src/matplotlib-git/matplotlib/build/lib.linux-i686-3.2/matplotlib/axes.py", 
line 2191, in ticklabel_format
     "This method only works with the ScalarFormatter.")

* I wanted some onmouseover() bubble annotation over specific markers but I
   gave up on this. Ideally I'd want to refer to the markers with a specific
   ID, give them different color style, and be able to add specific <title> or
   <text> elements where I want and manipulate them via javascript.

   Since I understand this is too much to ask from matplotlib I'd very much
   like the possibility to get the XML tree in some form *before* writing
   anything to disk. Does the SVG backend use the python xml.etree.ElementTree
   module? If only I could get the whole ElementTree, I would manipulate it as
   I'd like before writing to disk. What would you suggest to achieve the
   result I need?


I also had some difficulties with the website. For example when 
investigating various plotting utilities and checking their SVG output, I 
couldn't find anywhere the example from [1] rendered as SVG. The gallery 
is huge, but it is barely searchable (no text anywhere) so I still might 
have missed it. Secondly I'd appreciate a table of contents on top of the 
API pages, e.g. at http://matplotlib.sourceforge.net/api/pyplot_api.html

[1] http://matplotlib.sourceforge.net/examples/user_interfaces/svg_histogram.html


Finally, using more and more matplotlib I realised that some things are 
more complex than necessary. I'm talking specifically for when subplots or 
twin axes are involved. Then it is hard to keep a common legend (you have 
to keep track of the labels yourself). It is also hard to cycle the colors 
among the different axes (you have to keep track of the colors yourself). 
To have a common ylabel among the vertical subplots I just set the ylabel 
for the middle subplot, which seems like a hack. And also suptitle() seems 
weaker than title() (not bold, smaller font). Finally labels of yticks 
many times overlap each other at the border of adjascent subplots, so I 
have to manually compensate using set_major_locate() for sparser yticks.


Even though some things needed time-consuming hacks, matplotlib worked 
fine. Thanks for your work on this fantastic library!  And if you are 
curious you can see my automatic generated graphs (temporarily) at:

http://teras-ics.mooo.com:8003


thanks,
Dimitris


P.S. I sent this email (slightly changed) again a couple of months ago, 
but it got stuck in moderation. Thus I send it again now after 
subscribing, sorry if you get it twice.

Hello,

It appears that the Qt4Agg backend ignores any user defined 'resize_event'.
This program reproduces the issue (I am using the development version of
matplotlib from github):

import matplotlib
matplotlib.use('Qt4Agg')
import matplotlib.pyplot as plt

def say_hello(event):
    print "Hello"

fig = plt.figure()
fig.canvas.mpl_connect('resize_event', say_hello)
plt.show()

Resizing the figure does not result in "Hello" outputs, as it should.

The issue seems to be in lib/matplotlib/backends/backend_qt4.py, where
resizeEvent() looks like:

def resizeEvent( self, event ):
        if DEBUG: print('resize (%d x %d)' % (event.size().width(),
event.size().height()))
        w = event.size().width()
        h = event.size().height()
        if DEBUG: print("FigureCanvasQtAgg.resizeEvent(", w, ",", h, ")")
        dpival = self.figure.dpi
        winch = w/dpival
        hinch = h/dpival
        self.figure.set_size_inches( winch, hinch )
        self.draw()
        self.update()
        QtGui.QWidget.resizeEvent(self, event)
        
By comparison with the other surrounding event handlers, the callback to
FigureCanvasBase.resize_event() is manifestly missing. Indeed, adding

        FigureCanvasBase.resize_event(self)

at the end of resizeEvent() solves the problem.

Thanks,
Stefan

-- 
View this message in context: http://old.nabble.com/Matplotlib-Qt4Agg-backend-ignores-%27resize_event%27-tp34205981p34205981.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Mon, Jul 23, 2012 at 08:38:07PM -0400, Benjamin Root wrote:
> On Monday, July 23, 2012, Eric Firing wrote:
> 
> > On 2012/07/23 11:43 AM, Damon McDougall wrote:
> > > Hello all,
> > >
> > > So, as per Philip's suggestion
> > > (https://github.com/matplotlib/matplotlib/pull/737) I've started
> > > encapsulating fplot functionality into a class. The point of this is so
> > > that the user can call either of the following:
> > >
> > > FPlot_instance = ax.fplot(f, [x0, y0, x1, y1])
> > > ax.fplot(FPlot_instance, ...)
> >
> > The second of these seems odd to me; I would expect FPlot_instance to
> > have a __call__ method, so the normal use of an existing instance would be
> >

That is awesome! I didn't know the __call__ method existed! That's a
much better way of doing it. I love Python.

> >
> > FPlot_instance(...)
> >
> > Also, regarding the second argument in the first form: I would think it
> > more natural to split it up into a required [x0, x1] and an optional
> > [y0, y1], with autoscaling if it is not provided.
> >
> > Eric
> 
> 
> Agreed, it is a bit odd/awkward, and I also agree about autoscaling.
> 
> With the whole viewlims callbacks, make sure you have the class disconnect
> itself upon removal, such as through cla().
>

So are you suggesting autoscaling over a callback?

> l <https://lists.sourceforge.net/lists/listinfo/matplotlib-devel>
> Cheers!
> Ben Root

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Monday, July 23, 2012, Eric Firing wrote:

> On 2012/07/23 11:43 AM, Damon McDougall wrote:
> > Hello all,
> >
> > So, as per Philip's suggestion
> > (https://github.com/matplotlib/matplotlib/pull/737) I've started
> > encapsulating fplot functionality into a class. The point of this is so
> > that the user can call either of the following:
> >
> > FPlot_instance = ax.fplot(f, [x0, y0, x1, y1])
> > ax.fplot(FPlot_instance, ...)
>
> The second of these seems odd to me; I would expect FPlot_instance to
> have a __call__ method, so the normal use of an existing instance would be
>
> FPlot_instance(...)
>
> Also, regarding the second argument in the first form: I would think it
> more natural to split it up into a required [x0, x1] and an optional
> [y0, y1], with autoscaling if it is not provided.
>
> Eric


Agreed, it is a bit odd/awkward, and I also agree about autoscaling.

With the whole viewlims callbacks, make sure you have the class disconnect
itself upon removal, such as through cla().
l <https://lists.sourceforge.net/lists/listinfo/matplotlib-devel>
Cheers!
Ben Root

On 2012/07/23 11:43 AM, Damon McDougall wrote:
> Hello all,
>
> So, as per Philip's suggestion
> (https://github.com/matplotlib/matplotlib/pull/737) I've started
> encapsulating fplot functionality into a class. The point of this is so
> that the user can call either of the following:
>
> FPlot_instance = ax.fplot(f, [x0, y0, x1, y1])
> ax.fplot(FPlot_instance, ...)

The second of these seems odd to me; I would expect FPlot_instance to 
have a __call__ method, so the normal use of an existing instance would be

FPlot_instance(...)

Also, regarding the second argument in the first form: I would think it 
more natural to split it up into a required [x0, x1] and an optional 
[y0, y1], with autoscaling if it is not provided.

Eric

Hello all,

So, as per Philip's suggestion
(https://github.com/matplotlib/matplotlib/pull/737) I've started
encapsulating fplot functionality into a class. The point of this is so
that the user can call either of the following:

FPlot_instance = ax.fplot(f, [x0, y0, x1, y1])
ax.fplot(FPlot_instance, ...)

Each of these is valid. The first does 'the obvious', as seen in the
closed PR above. The second takes an instance of an FPlot object,
presumably the user would also pass new limits to, say, zoom out. Then
the plot is updated as necessary. This was also Philip's suggestion and
there is a nice working example of changing the limits of a plot to get
a more highly resolved image in examples/event_handling/viewlims.py

I haven't put in a new pull request because I can't decide which of
these methods is better. In short, the viewlims.py example uses a
callback to adjust the plot if the user calls set_xlim or set_ylim.
Would it be sensible to use a callback for fplot buried in the FPlot
class or use my initial thought, which is to pass in a new tuple
describing the new axes limits and update if necessary?

The code isn't complete so I'm reluctant to file a new PR, but if there
is overwhelming desire for people to see the code (perhaps due to my
poor explanation) then I'll open a new PR so everyone can give their two
pence.

Suggestions welcome :)

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Fri, Jul 20, 2012 at 3:21 PM, John Hunter <jd...@gm...> wrote:

> I would like to discuss a timetable towards a python3 release (1.2 or
> 2.0).  I'll throw this out there, and am happy to make modifications
> according to feedback
>
> Aug 20th : feature freeze and branch.  bugfixes only going forward from
> this point
>
> Sept 15th: rc1
>
> Oct 7th: rc2
>
> Oct 15th release
>
> I know we have lots of open and interesting pull requests to get in, and
> so if we need to push these times back to get them in that is fine.  Just
> wanted to put something out there to see if this timeline seems plausible
> to people.
>
> JDH
>
>
I think the schedule is reasonable.  We are going to need significant help
getting through our backlog of PRs.  At the very least, we need to identify
which ones are release critical or not.

Just as a note, I don't know whether or not we want to have my axes.py
refactor included in this release or not.  If most of my attention is going
to be on the documentation and PR push, it is extremely unlikely I am going
to get much further with it in the next couple of months.

Ben Root

Dear macosx backend users,

Could you please have a look at pull request 
https://github.com/matplotlib/matplotlib/pull/1036. It removes a minor 
annoyance where only the last figure would appear to the front after 
issuing a non-interactive show().

It builds upon https://github.com/matplotlib/matplotlib/pull/663, 
delivered with matplotlib 1.1.1.

Cheers,

-Gellule

On Fri, Jul 20, 2012 at 3:20 PM, Eric Firing <ef...@ha...> wrote:
> This would be defeating the basic idea: use() is *only* designed to take
> effect *once*.  If you need to switch backends, it takes more than what
> use() does, hence the need for switch_backend().  (But see below.)
>
> The warn=False invocation of use, with the return statement were it is
> now, is for the case where you may have a script or module that
> specifies a backend (in case it is the first or only import of
> matplotlib), but that may itself be imported or called by something else
> that has already imported matplotlib and set the backend.  In this case
> we want the warning to be suppressed, which is all the warn=False flag
> is supposed to do.  I use this myself.
>
> So it looks like the problem is that switch_backends is broken because
> what it needs matplotlib.use to do is go ahead and make the switch. This
> could be done by adding a force=True kwarg (default would be False) to
> matplotlib.use, or by deleting the reference to the backends module from
> sys.modules in switch_backends before calling matplotlib.use.  A
> variation would be to use the force kwarg and to include the
> switch_backends logic, or at least the reload line, in matplotlib.use.
> That probably makes sense: add the force kwarg, and when the module is
> replaced, reload it immediately within matplotlib.use.  Then
> pyplot.switch_backends only needs to do the pyplot-specific operations.
>   I think that is the cleanest solution.

I agree, this is a better way to go. (And occurred to me as well after
the initial PR.)

Glad I asked rather than doing my 2-line fix. The updated PR is at
https://github.com/matplotlib/matplotlib/pull/1028

Ryan

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jul 20, 2012 at 3:20 PM, Eric Firing <ef...@ha...> wrote:

> On 2012/07/20 9:34 AM, Ryan May wrote:
> > Hi,
> >
> > I'm here at the SciPy sprints trying to fix switching inline/gui for
> > the ipython notebook. I've noticed something weird about
> > matplotlib.use() :
> >
> >      if 'matplotlib.backends' in sys.modules:
> >          if warn: warnings.warn(_use_error_msg)
> >          return
> >      if arg.startswith('module://'):
> >          name = arg
> >      else:
> >          # Lowercase only non-module backend names (modules are
> case-sensitive)
> >          arg = arg.lower()
> >          name = validate_backend(arg)
> >      rcParams['backend'] = name
> >
> > Notice the return if it finds the module loaded. This return basically
> > makes it impossible to make use() have any effect one backends has
> > been loaded. However, matplotlib.pyplot.switch_backend(). Eric added
> > this in 2008 as a bug fix, but no more detail than that. Does anyone
> > have a problem putting the return with the warning? Therefore if you
> > pass warn=False, you can actually make the setting take effect, but
> > the average user won't accidentally shoot their foot off. Something
> > like:
> >
> >      if 'matplotlib.backends' in sys.modules:
> >          if warn:
> >              warnings.warn(_use_error_msg)
> >              return
>
> This would be defeating the basic idea: use() is *only* designed to take
> effect *once*.  If you need to switch backends, it takes more than what
> use() does, hence the need for switch_backend().  (But see below.)
>
> The warn=False invocation of use, with the return statement were it is
> now, is for the case where you may have a script or module that
> specifies a backend (in case it is the first or only import of
> matplotlib), but that may itself be imported or called by something else
> that has already imported matplotlib and set the backend.  In this case
> we want the warning to be suppressed, which is all the warn=False flag
> is supposed to do.  I use this myself.
>
> So it looks like the problem is that switch_backends is broken because
> what it needs matplotlib.use to do is go ahead and make the switch. This
> could be done by adding a force=True kwarg (default would be False) to
> matplotlib.use, or by deleting the reference to the backends module from
> sys.modules in switch_backends before calling matplotlib.use.  A
> variation would be to use the force kwarg and to include the
> switch_backends logic, or at least the reload line, in matplotlib.use.
> That probably makes sense: add the force kwarg, and when the module is
> replaced, reload it immediately within matplotlib.use.  Then
> pyplot.switch_backends only needs to do the pyplot-specific operations.
>   I think that is the cleanest solution.
>
> Eric
>
>
I like the "force" idea very much.  It means exactly what it says.

Ben Root

On 2012/07/20 9:34 AM, Ryan May wrote:
> Hi,
>
> I'm here at the SciPy sprints trying to fix switching inline/gui for
> the ipython notebook. I've noticed something weird about
> matplotlib.use() :
>
>      if 'matplotlib.backends' in sys.modules:
>          if warn: warnings.warn(_use_error_msg)
>          return
>      if arg.startswith('module://'):
>          name = arg
>      else:
>          # Lowercase only non-module backend names (modules are case-sensitive)
>          arg = arg.lower()
>          name = validate_backend(arg)
>      rcParams['backend'] = name
>
> Notice the return if it finds the module loaded. This return basically
> makes it impossible to make use() have any effect one backends has
> been loaded. However, matplotlib.pyplot.switch_backend(). Eric added
> this in 2008 as a bug fix, but no more detail than that. Does anyone
> have a problem putting the return with the warning? Therefore if you
> pass warn=False, you can actually make the setting take effect, but
> the average user won't accidentally shoot their foot off. Something
> like:
>
>      if 'matplotlib.backends' in sys.modules:
>          if warn:
>              warnings.warn(_use_error_msg)
>              return

This would be defeating the basic idea: use() is *only* designed to take 
effect *once*.  If you need to switch backends, it takes more than what 
use() does, hence the need for switch_backend().  (But see below.)

The warn=False invocation of use, with the return statement were it is 
now, is for the case where you may have a script or module that 
specifies a backend (in case it is the first or only import of 
matplotlib), but that may itself be imported or called by something else 
that has already imported matplotlib and set the backend.  In this case 
we want the warning to be suppressed, which is all the warn=False flag 
is supposed to do.  I use this myself.

So it looks like the problem is that switch_backends is broken because 
what it needs matplotlib.use to do is go ahead and make the switch. This 
could be done by adding a force=True kwarg (default would be False) to 
matplotlib.use, or by deleting the reference to the backends module from 
sys.modules in switch_backends before calling matplotlib.use.  A 
variation would be to use the force kwarg and to include the 
switch_backends logic, or at least the reload line, in matplotlib.use. 
That probably makes sense: add the force kwarg, and when the module is 
replaced, reload it immediately within matplotlib.use.  Then 
pyplot.switch_backends only needs to do the pyplot-specific operations. 
  I think that is the cleanest solution.

Eric



>
>
> Ryan
>

Hi,

I'm here at the SciPy sprints trying to fix switching inline/gui for
the ipython notebook. I've noticed something weird about
matplotlib.use() :

    if 'matplotlib.backends' in sys.modules:
        if warn: warnings.warn(_use_error_msg)
        return
    if arg.startswith('module://'):
        name = arg
    else:
        # Lowercase only non-module backend names (modules are case-sensitive)
        arg = arg.lower()
        name = validate_backend(arg)
    rcParams['backend'] = name

Notice the return if it finds the module loaded. This return basically
makes it impossible to make use() have any effect one backends has
been loaded. However, matplotlib.pyplot.switch_backend(). Eric added
this in 2008 as a bug fix, but no more detail than that. Does anyone
have a problem putting the return with the warning? Therefore if you
pass warn=False, you can actually make the setting take effect, but
the average user won't accidentally shoot their foot off. Something
like:

    if 'matplotlib.backends' in sys.modules:
        if warn:
            warnings.warn(_use_error_msg)
            return


Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

I would like to discuss a timetable towards a python3 release (1.2 or 2.0).
 I'll throw this out there, and am happy to make modifications according to
feedback

Aug 20th : feature freeze and branch.  bugfixes only going forward from
this point

Sept 15th: rc1

Oct 7th: rc2

Oct 15th release

I know we have lots of open and interesting pull requests to get in, and so
if we need to push these times back to get them in that is fine.  Just
wanted to put something out there to see if this timeline seems plausible
to people.

JDH

On 07/19/2012 09:37 AM, Benjamin Root wrote:
>
>
> On Thu, Jul 19, 2012 at 2:32 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 07/19/2012 09:24 AM, Benjamin Root wrote:
>      > Working on my refactor of axes.py, I needed to use defaultdict and
>      > possibly OrderedDict from the collections standard module.
>       Problem is
>      > that matplotlib already has a collections.py module in
>     lib/matplotlib.
>      > This file takes precedence in the import process and gets in my way.
>      > Does anybody know of any way to force the import to do what I want?
>      > This has completely stumped me.
>
>     Looking at http://www.python.org/dev/peps/pep-0328/ it appears that for
>     2.6 and later, using
>
>     from __future__ import absolute_import
>
>     should cause "import collections" to refer to the standard library.
>
>     Eric
>
>
> Good to know.  But aren't we supporting 2.5, or did we decide on 2.6?

 >=2.6 only from now on.  This is so that we can support 3.2+ in the 
same codebase.

Eric

>
> Ben
>

On Thu, Jul 19, 2012 at 2:32 PM, Eric Firing <ef...@ha...> wrote:

> On 07/19/2012 09:24 AM, Benjamin Root wrote:
> > Working on my refactor of axes.py, I needed to use defaultdict and
> > possibly OrderedDict from the collections standard module.  Problem is
> > that matplotlib already has a collections.py module in lib/matplotlib.
> > This file takes precedence in the import process and gets in my way.
> > Does anybody know of any way to force the import to do what I want?
> > This has completely stumped me.
>
> Looking at http://www.python.org/dev/peps/pep-0328/ it appears that for
> 2.6 and later, using
>
> from __future__ import absolute_import
>
> should cause "import collections" to refer to the standard library.
>
> Eric
>
>
Good to know.  But aren't we supporting 2.5, or did we decide on 2.6?

Ben

On 07/19/2012 09:24 AM, Benjamin Root wrote:
> Working on my refactor of axes.py, I needed to use defaultdict and
> possibly OrderedDict from the collections standard module.  Problem is
> that matplotlib already has a collections.py module in lib/matplotlib.
> This file takes precedence in the import process and gets in my way.
> Does anybody know of any way to force the import to do what I want?
> This has completely stumped me.

Looking at http://www.python.org/dev/peps/pep-0328/ it appears that for 
2.6 and later, using

from __future__ import absolute_import

should cause "import collections" to refer to the standard library.

Eric

>
> Thanks,
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Working on my refactor of axes.py, I needed to use defaultdict and possibly
OrderedDict from the collections standard module.  Problem is that
matplotlib already has a collections.py module in lib/matplotlib.  This
file takes precedence in the import process and gets in my way.  Does
anybody know of any way to force the import to do what I want?  This has
completely stumped me.

Thanks,
Ben Root

On Thu, Jul 19, 2012 at 5:39 AM, Philippe MALLET
<phi...@ce...> wrote:
> Dear all,
>
> When I use the Qt4Agg backend and I want to save the figure by clicking the
> save button, I get this Error message:
>
> kfilemodule(5951): couldn't create slave: "Unable to create io-slave:
> klauncher said: Protocole «  » inconnu.
>
> It is like an empty string is given for the protocole name.
>
> infos:
> Distribution: Archlinux
> Python 2.7.3
> matplotlib 1.1.1
> Kde 4.8.4
> Linux  3.4.5-1-ARCH x86_64

I don't think this is a matplotlib bug. It is probably a KDE
configuration problem specific to your system. See
http://forums.gentoo.org/viewtopic-t-601154.html.

You could try editing your backend_qt4.py, in the save_figure method,
to add QFileDialog.DontUseNativeDialog to the end of the list of
arguments passed to _getSaveFileName. But that is only a workaround.

Darren

Le jeudi 19 juillet 2012 08:18:14 Benjamin Root a écrit :




On Thu, Jul 19, 2012 at 4:43 AM, Philippe MALLET <phi...@ce...> 
wrote:

Dear all,
 
when I use the GTKAgg backend, I get the following message when I launch 
Ipython -pylab:
 
** (process:27239): WARNING **: Trying to register gtype 'GMountMountFlags' as 
enum when in fact it is of type 'GFlags' 
 
** (process:27239): WARNING **: Trying to register gtype 'GDriveStartFlags' as 
enum when in fact it is of type 'GFlags' 
 
** (process:27239): WARNING **: Trying to register gtype 'GSocketMsgFlags' as 
enum when in fact it is of type 'GFlags' 
 
Infos:
Distribution: Archlinux
Python 2.7.3
matplotlib 1.1.1
Linux  3.4.5-1-ARCH x86_64

Best regards,



Phillippe,

What is the full version number of GTK on your system (i.e., #.#.#)?

Cheers!
Ben Root



Sorry I forgot to mention it:
gtk 1.2.10
gtk2 2.24.10
gtk3 3.4.3
pygtk 2.24

Cheers!

On Thu, Jul 19, 2012 at 4:39 AM, Philippe MALLET
<phi...@ce...>wrote:

> Dear all,
>
> When I use the Qt4Agg backend and I want to save the figure by clicking the
> save button, I get this Error message:
>
> kfilemodule(5951): couldn't create slave: "Unable to create io-slave:
> klauncher said: Protocole «  » inconnu.
>
> It is like an empty string is given for the protocole name.
>
> infos:
> Distribution: Archlinux
> Python 2.7.3
> matplotlib 1.1.1
> Kde 4.8.4
> Linux  3.4.5-1-ARCH x86_64
>
> Best regards,
>
>
Philippe,

Was there a more complete traceback displayed?

Ben Root

On Thu, Jul 19, 2012 at 4:43 AM, Philippe MALLET
<phi...@ce...>wrote:

> **
>
> Dear all,
>
>
>
> when I use the GTKAgg backend, I get the following message when I launch
> Ipython -pylab:
>
>
>
> ** (process:27239): WARNING **: Trying to register gtype
> 'GMountMountFlags' as enum when in fact it is of type 'GFlags'
>
>
>
> ** (process:27239): WARNING **: Trying to register gtype
> 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
>
>
>
> ** (process:27239): WARNING **: Trying to register gtype 'GSocketMsgFlags'
> as enum when in fact it is of type 'GFlags'
>
>
>
> Infos:
>
> Distribution: Archlinux
>
> Python 2.7.3
>
> matplotlib 1.1.1
>
> Linux  3.4.5-1-ARCH x86_64
>
> Best regards,
>
>
Phillippe,

What is the full version number of GTK on your system (i.e., #.#.#)?

Cheers!
Ben Root

Dear all,

when I use the GTKAgg backend, I get the following message when I launch 
Ipython -pylab:

** (process:27239): WARNING **: Trying to register gtype 'GMountMountFlags' as 
enum when in fact it is of type 'GFlags'

** (process:27239): WARNING **: Trying to register gtype 'GDriveStartFlags' as 
enum when in fact it is of type 'GFlags'

** (process:27239): WARNING **: Trying to register gtype 'GSocketMsgFlags' as 
enum when in fact it is of type 'GFlags'

Infos:
Distribution: Archlinux
Python 2.7.3
matplotlib 1.1.1
Linux  3.4.5-1-ARCH x86_64

Best regards,