headers
Darren Dale | 1 Dec 17:09
Picon
Gravatar

Re: Enhancement to matplotlib's PyQt4 backend

On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut <contact <at> pythonxy.com> wrote:
> Hi all,
>
> I would like to contribute to matplotlib with this enhancement for the
> PyQt4 backend: the idea is to add a toolbar button to configure figure
> options (axes, curves, ...).
>
> It's based on a tiny module called formlayout to generate PyQt4 form
> dialog automatically.
>
> Some screenshots:
> http://code.google.com/p/formlayout/
>
> So, if you're interested (all the following is GPL2):
>
> *matplotlib patch*

Would you please submit an actual patch? I don't know exactly where
you intend these changes to be placed.

> In FigureManagerQT.__init__, added:
> self.canvas.axes = self.canvas.figure.add_subplot(111)

What is the purpose of this change? What if I didn't want such an axes
on my canvas? What if I want to layout my own axes([.2,.2,.75,.75]) or
add_subplot(311)? I don't think these changes can be accepted in the
current form, they don't appear to integrate well with the standard
behavior of the library.

> In NavigationToolbar2QT._init_toolbar, added:
(Continue reading)

Permalink | Reply | 13 comments |
headers
James Evans | 2 Dec 00:52
Picon
Favicon

Z-Order Sorting

All,

I have been looking at some of the recent z-order changes and have found an issue that breaks previous
behavior.  Previously when
items were added to a Figure or an Axes with the same z-order value, they were rendered in order of when they
were added, so that
the first one added is 'underneath' the others and the last one added is rendered 'over' all the other items
of the same z-order
value.  This no longer is the case.  The following snippet of code demonstrates the problem:

#===============================================================
class ZSortClass( object ):
   def __init__( self, name, zorder = 0 ):
      self.name = name
      self.zorder = zorder
   def doit( self ):
      print "z-order [%s] = %s" % (self.name, self.zorder)

# Instantiate out of order to prove a point
a = ZSortClass( 'a', 0 )
c = ZSortClass( 'c', 0 )
b = ZSortClass( 'b', 0 )

all = [ a, b, c ]
dsu = [ (x.zorder, x.doit, x.name) for x in all ]

print dsu
dsu.sort()
print dsu
#===============================================================
(Continue reading)

Permalink | Reply | 7 comments |
headers
Eric Firing | 2 Dec 02:15
Favicon
Gravatar

Re: Z-Order Sorting

James Evans wrote:
> All,
> 
> I have been looking at some of the recent z-order changes and have found an issue that breaks previous
behavior.  Previously when
> items were added to a Figure or an Axes with the same z-order value, they were rendered in order of when they
were added, so that
> the first one added is 'underneath' the others and the last one added is rendered 'over' all the other items
of the same z-order
> value.  This no longer is the case.  The following snippet of code demonstrates the problem:
> 
> #===============================================================
> class ZSortClass( object ):
>    def __init__( self, name, zorder = 0 ):
>       self.name = name
>       self.zorder = zorder
>    def doit( self ):
>       print "z-order [%s] = %s" % (self.name, self.zorder)
> 
> # Instantiate out of order to prove a point
> a = ZSortClass( 'a', 0 )
> c = ZSortClass( 'c', 0 )
> b = ZSortClass( 'b', 0 )
> 
> all = [ a, b, c ]
> dsu = [ (x.zorder, x.doit, x.name) for x in all ]
> 
> print dsu
> dsu.sort()
> print dsu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Firing | 2 Dec 01:21
Favicon
Gravatar

Re: Z-Order Sorting

James Evans wrote:
> All,
> 
> I have been looking at some of the recent z-order changes and have found an issue that breaks previous
behavior.  Previously when
> items were added to a Figure or an Axes with the same z-order value, they were rendered in order of when they
were added, so that
> the first one added is 'underneath' the others and the last one added is rendered 'over' all the other items
of the same z-order
> value.  This no longer is the case.  The following snippet of code demonstrates the problem:
> 
> #===============================================================
> class ZSortClass( object ):
>    def __init__( self, name, zorder = 0 ):
>       self.name = name
>       self.zorder = zorder
>    def doit( self ):
>       print "z-order [%s] = %s" % (self.name, self.zorder)
> 
> # Instantiate out of order to prove a point
> a = ZSortClass( 'a', 0 )
> c = ZSortClass( 'c', 0 )
> b = ZSortClass( 'b', 0 )
> 
> all = [ a, b, c ]
> dsu = [ (x.zorder, x.doit, x.name) for x in all ]
> 
> print dsu
> dsu.sort()
> print dsu
(Continue reading)

Permalink | Reply | 5 comments |
headers
John Hunter | 2 Dec 03:41
Picon
Gravatar

Re: Z-Order Sorting

On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing <efiring@...> wrote:
> This is easy to fix by using the key kwarg (added in python 2.4) of the
> sort method, because python uses a stable sort.  It looks like it only
> needs to be fixed in Axes.draw, because Figure.draw has never paid any
> attention to zorder anyway.  I'll do it now.

It does now in svn HEAD -- I just added this yesterday.

JDH

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
Permalink | Reply | 4 comments |
headers
Eric Firing | 2 Dec 05:17
Favicon
Gravatar

Re: Z-Order Sorting

John Hunter wrote:
> On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing <efiring@...> wrote:
>> This is easy to fix by using the key kwarg (added in python 2.4) of the
>> sort method, because python uses a stable sort.  It looks like it only
>> needs to be fixed in Axes.draw, because Figure.draw has never paid any
>> attention to zorder anyway.  I'll do it now.
> 
> It does now in svn HEAD -- I just added this yesterday.

Yes, I saw that after I sent the first message, so I stabilized the sort 
  in Figure.draw also.

Eric

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
Permalink | Reply | 3 comments |
headers
Tony S Yu | 5 Dec 21:12
Picon
Gravatar

Weird windowing issues since last update of OS X 10.6

I updated to the newest release of OS X---10.6.2---last night and I've been getting a weird windowing error
for certain backends. 

I'm able to reproduce the error with the following: run a simple plot script (which calls plt.show) from the
terminal. Close the figure. The problem is:

* tkagg: window closes, but it doesn't return control to the terminal (i.e. terminal hangs).
* macosx: axis is cleared from the figure window, but the window (w/o axis) remains and terminal hangs.
* qt4agg: works fine.

Alternatively, I can run the script from ipython. In this case, tkagg and qt4agg work as normal. The macosx
backend hangs, the window does not close, and control is not returned to ipython.

In all cases, the plot shows up fine (it just doesn't always close properly). Running the script with python
-vv doesn't help: All the debug code it prints stops before plt.show is called. I wish I could provide more
debug output, but I'm not sure how.

Any ideas?

-Tony

PS. To add another piece to the mystery, I've been having problems running plot scripts from my text editor
(Textmate): python hangs **before** plotting. I've traced the hang to a call to
matplotlib.backends.pylab_setup.new_figure_manager, but I really don't understand where exactly
hangs. Again: this only happens when running from Textmate, and started happening about a week ago
(following a Textmate update). My guess is that this is a Textmate-related issue, but I thought I'd
mention it in case these two issues combined suggest a more fundamental problem with my python install.
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Reinier Heeres | 10 Dec 01:13
Picon

Re: 3D Axes scatter : no possibility to vary color/size of markers

Hi,

Thanks for reporting this bug, I fixed it in svn. In the maintenance
branch as well, so it will appear in next releases.

Regards,
Reinier

On Thu, Nov 19, 2009 at 4:14 PM, John Hunter <jdh2358@...> wrote:
> On Thu, Nov 19, 2009 at 6:02 AM, Ensitof <ensieta.leroy@...> wrote:
>>
>> I got the same problem and posted my question in this forum
>> http://www.developpez.net/forums/d836964/autres-langages/python-zope/calcul-scientifique/matplotlib-scatter3d-colorisation-fonction-z/
>> (here)  a few days ago... My question receives a lot of visits but no
>> reaction however I think it may be an important information for people
>> wanting to use matplotlib efficiently. Please let me know if you can find
>> anything about it :confused: Even if everything works perfect with 2D
>> scatter I can't solve this issue with scatter3D. Knowing that's it's a bug
>> should already be a nice answer...
>>
>
> Please file a bug on the tracker and I will assign it to Reinier
>
> http://sourceforge.net/tracker/?atid=560720&group_id=80706&func=browse
>
> Thanks,
> JDH
>

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jae-Joon Lee | 11 Dec 18:07
Picon
Gravatar

Re: Z-Order Sorting

The recent zorder-related  changes broke the some of the rasterization
feature, and I just committed a fix. In doing so, I replaced

        dsu.sort(key=lambda x: x[0])

to

        dsu.sort(key=itemgetter(0))

which I think is slightly faster (although speed is not much of concern here).

Regards,

-JJ

On Tue, Dec 1, 2009 at 11:17 PM, Eric Firing <efiring <at> hawaii.edu> wrote:
> John Hunter wrote:
>> On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing <efiring <at> hawaii.edu> wrote:
>>> This is easy to fix by using the key kwarg (added in python 2.4) of the
>>> sort method, because python uses a stable sort.  It looks like it only
>>> needs to be fixed in Axes.draw, because Figure.draw has never paid any
>>> attention to zorder anyway.  I'll do it now.
>>
>> It does now in svn HEAD -- I just added this yesterday.
>
> Yes, I saw that after I sent the first message, so I stabilized the sort
>  in Figure.draw also.
>
> Eric
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane