wx back-end bugs/issues

Hi all,

I usually use MPL embedded in wx, so I haven't noticed these before but with the pylab window:

1) A couple icons seem to be missing. See screenshot enclosed.

2) The save button doesn't work, as I get a "cannot return std::string from a Unicode object" error. This is with a unicode build of wxPython. I've had this same problem with my code. This issue is that the savefig code can't handle unicode (regular old fopen, I think). Here are two solutions:

1) use:

filename.encode('ASCII', 'replace')

on the string before using it, so that you'll get an odd name with non-ascii charactors but at least it will work.

2) Use:
F.savefig(open(path, "w"), dpi=dpi)

Python's open allows unicode filenames, and I was told that recent versions of MPL can take a file, rather than just aname, without an unacceptable performance hit, though in my code, without the latest MPL, I get an invalid PNG.

thanks,
-Chris

MPL_wx.png

···

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

Chris.Barker@...236...

Chris Barker wrote:

Hi all,

I usually use MPL embedded in wx, so I haven't noticed these before but with the pylab window:

1) A couple icons seem to be missing. See screenshot enclosed.

I believe that's the way disabled buttons are drawn on Windows (or perhaps we need to provide disabled versions of the bitmaps on Windows). Do they appear after you have panned/zoomed the plot?

2) The save button doesn't work, as I get a "cannot return std::string from a Unicode object" error. This is with a unicode build of wxPython. I've had this same problem with my code. This issue is that the savefig code can't handle unicode (regular old fopen, I think). Here are two solutions:

1) use:

filename.encode('ASCII', 'replace')

on the string before using it, so that you'll get an odd name with non-ascii charactors but at least it will work.

That seems undesirable -- you'll end up with a filename with question marks in it.

2) Use:
F.savefig(open(path, "w"), dpi=dpi)

This is exactly what matplotlib the *Agg backends do on the 0.91.x maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest release) still has this bug. This may be reason enough to push out a new maintenance release of 0.91.x, but I say that having done it before :wink:

Python's open allows unicode filenames, and I was told that recent versions of MPL can take a file, rather than just aname, without an unacceptable performance hit, though in my code, without the latest MPL, I get an invalid PNG.

Which version of MPL produces an invalid PNG? I'd like to track that down. It may be Windows-specific.

Cheers,
Mike

···

------------------------------------------------------------------------

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
------------------------------------------------------------------------

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Chris Barker schrieb:

Hi all,

I usually use MPL embedded in wx, so I haven't noticed these before but with the pylab window:

1) A couple icons seem to be missing. See screenshot enclosed.

I also discovered this behaviour. It seems to be a Windows only specific behaviour that only affects the bitmaps of the disabled (or grayed out) toolbar buttons. A solution I found is to use the png toolbar bitmaps instead of of the xpm ones. For this, replace in backend_wx.py, NavigationToolbar2Wx::_init_toolbar() 'home.xpm' by 'home.png', etc. In the same file, in _load_bitmap() replace wx.BITMAP_TYPE_XPM by wx.BITMAP_TYPE_PNG. This also gives a better visual impression since the png bitmaps have an alpha channel, see attached file. Furthermore, in my opinion, the floppy symbol is too small compared to the other icons. I also attached a magnified version.

Gregor

toolbar2.png

save.png

Thankso Gregor -- I made these changes XPM->PNG for toolbar2 on the
svn branch and trunk, but I don't have ready access to wx here, so if
you or another wx svn user gets a chance to check, that would be
great. Else I can do it tonight from home.

JDH

···

On Tue, May 6, 2008 at 8:49 AM, Gregor Thalhammer <gregor.thalhammer@...149...> wrote:

I also discovered this behaviour. It seems to be a Windows only specific
behaviour that only affects the bitmaps of the disabled (or grayed out)
toolbar buttons. A solution I found is to use the png toolbar bitmaps
instead of of the xpm ones. For this, replace in backend_wx.py,
NavigationToolbar2Wx::_init_toolbar() 'home.xpm' by 'home.png', etc. In the
same file, in _load_bitmap() replace wx.BITMAP_TYPE_XPM by
wx.BITMAP_TYPE_PNG. This also gives a better visual impression since the png
bitmaps have an alpha channel, see attached file. Furthermore, in my
opinion, the floppy symbol is too small compared to the other icons. I also
attached a magnified version.

Michael Droettboom wrote:

1) A couple icons seem to be missing. See screenshot enclosed.

It looks like Gregor solved this one.

1) use:

filename.encode('ASCII', 'replace')

on the string before using it, so that you'll get an odd name with non-ascii charactors but at least it will work.

That seems undesirable -- you'll end up with a filename with question marks in it.

Better than than a crash, and no way to save a figure, even with a pure-ascii filename. You could use latin-1, or even better, something from a system setting, though I have no idea if that's doable. The real solution is to allow MPL to take unicode file names -- most modern file systems are using unicode now.

2) Use:
F.savefig(open(path, "w"), dpi=dpi)

This is exactly what matplotlib the *Agg backends do on the 0.91.x maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest release) still has this bug.

Darn.

This may be reason enough to push out a new maintenance release of 0.91.x,

Could be -- it's kind of a show stopper.

MPL, I get an invalid PNG.

Which version of MPL produces an invalid PNG?

0.91.2

and yes, I think it is a Window bug -- I'm pretty sure it works fine on OS-X.

Thanks,

-CHB

···

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

Chris.Barker@...236...

  1. Use:

F.savefig(open(path, “w”), dpi=dpi)

This is exactly what matplotlib the *Agg backends do on the 0.91.x

maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest

release) still has this bug. This may be reason enough to push out a

new maintenance release of 0.91.x, but I say that having done it before :wink:

This is a really stopper for me, I have to interact with my figures before saving them, and it is a really annoying behavior.

Were should this patch be applied ?

+1 for a new maintenance release.

I was searching for an answer to this, I’m glad the error was known and the fix available, so thanks :slight_smile:

Matthieu

···

French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92

LinkedIn : http://www.linkedin.com/in/matthieubrucher

John Hunter schrieb:

···

On Tue, May 6, 2008 at 8:49 AM, Gregor Thalhammer > <gregor.thalhammer@...149...> wrote:

I also discovered this behaviour. It seems to be a Windows only specific
behaviour that only affects the bitmaps of the disabled (or grayed out)
toolbar buttons. A solution I found is to use the png toolbar bitmaps
instead of of the xpm ones. For this, replace in backend_wx.py,
NavigationToolbar2Wx::_init_toolbar() 'home.xpm' by 'home.png', etc. In the
same file, in _load_bitmap() replace wx.BITMAP_TYPE_XPM by
wx.BITMAP_TYPE_PNG. This also gives a better visual impression since the png
bitmaps have an alpha channel, see attached file. Furthermore, in my
opinion, the floppy symbol is too small compared to the other icons. I also
attached a magnified version.
    
Thankso Gregor -- I made these changes XPM->PNG for toolbar2 on the
svn branch and trunk, but I don't have ready access to wx here, so if
you or another wx svn user gets a chance to check, that would be
great. Else I can do it tonight from home.

I checked the svn version (on Linux), works well. On Windows, applying these changes manually, I could see grayed out toolbox icons.

Gregor

Unfortunately, the fix requires recompiling C code. If you're comfortable doing that, the easiest thing is just to check out the svn branch here:

http://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_91_maint

But for those not doing that, I think a new release is in order, but I'm not the one who normally makes those calls etc.

Cheers,
Mike

Matthieu Brucher wrote:

···

    > 2) Use:
    > F.savefig(open(path, "w"), dpi=dpi)
    This is exactly what matplotlib the *Agg backends do on the 0.91.x
    maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest
    release) still has this bug. This may be reason enough to push out a
    new maintenance release of 0.91.x, but I say that having done it
    before :wink:

This is a really stopper for me, I have to interact with my figures before saving them, and it is a really annoying behavior.
Were should this patch be applied ?

+1 for a new maintenance release.

I was searching for an answer to this, I'm glad the error was known and the fix available, so thanks :slight_smile:

Matthieu
--
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
------------------------------------------------------------------------

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

This is not a problem, I compile new nersions of differnet paclages regularly.

I’ll checkout the branch, many thanks !

Matthieu

2008/5/7 Michael Droettboom <mdroe@…31…>:

···

Unfortunately, the fix requires recompiling C code. If you’re comfortable doing that, the easiest thing is just to check out the svn branch here:

http://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_91_maint

But for those not doing that, I think a new release is in order, but I’m not the one who normally makes those calls etc.

Cheers,

Mike

Matthieu Brucher wrote:

> 2) Use:

> F.savefig(open(path, "w"), dpi=dpi)

This is exactly what matplotlib the *Agg backends do on the 0.91.x

maintenance branch and the trunk.  Unfortunately, 0.91.2 (the latest

release) still has this bug.  This may be reason enough to push out a

new maintenance release of 0.91.x, but I say that having done it

before ;)

This is a really stopper for me, I have to interact with my figures before saving them, and it is a really annoying behavior.

Were should this patch be applied ?

+1 for a new maintenance release.

I was searching for an answer to this, I’m glad the error was known and the fix available, so thanks :slight_smile:

Matthieu

French PhD student

Website : http://matthieu-brucher.developpez.com/

Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92

LinkedIn : http://www.linkedin.com/in/matthieubrucher



This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don’t miss this year’s exciting event. There’s still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone



Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Michael Droettboom

Science Software Branch

Operations and Engineering Division

Space Telescope Science Institute

Operated by AURA for NASA


French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92

LinkedIn : http://www.linkedin.com/in/matthieubrucher