Menu
▾
▴
matplotlib-devel
|
From: Steve C. <ste...@ya...> - 2005-09-18 15:08:39
|
On Wed, 2005-09-14 at 20:32 -0700, John Hunter wrote: > OK, great. Steve could you take a look at this when you get a > minute > and give some feedback about whether you think this is a god > idea. The patch works OK when I tried it, and the example displayed a button in the FigureCanvas. How is it extremely useful to place a widget on top of a FigureCanvas? I think a figure widget should just show figures, extra widgets can always be placed outside the figure widget. Gtk.DrawingArea is a simple, fast widget. Gtk.Layout (as used by GnomeCanvas) is more complicated and has a higher overhead. This week I read that the widget item in gnome-canvas does not work very well http://blogs.gnome.org/view/alexl/2005/09/14/0 Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: Abraham S. <ab...@cn...> - 2005-09-18 20:47:34
|
Currently matplotlib already draws its widgets on the canvas, so this would allow a method to instead use native widgets in place of the matplotlib widgets when possible. Using native widgets has the advantage of response time and having a larger library at one's disposal. Even without the mapping of matplotlib->native widgets, it can be useful to easily put more controls to allow the plot to be altered (e.g. playing a movie, rerunning a sim, etc.) This can also be accomplished (at least with GTK) by adding another toolbar, but isn't always optimal. Is there an easy method to place widgets outside of the figure widget? Also, does this mean that matplotlib widgets should also not be drawn on the canvas? I checked on the link you gave, and it appears the problem occurs when scrolling is involved. Currently with how things are done, I don't think this will happen. Abe Steve Chaplin wrote: >On Wed, 2005-09-14 at 20:32 -0700, John Hunter wrote: > > >> OK, great. Steve could you take a look at this when you get a >> minute >> and give some feedback about whether you think this is a god >> idea. >> >> > >The patch works OK when I tried it, and the example displayed a button >in the FigureCanvas. How is it extremely useful to place a widget on top >of a FigureCanvas? > >I think a figure widget should just show figures, extra widgets can >always be placed outside the figure widget. >Gtk.DrawingArea is a simple, fast widget. Gtk.Layout (as used by >GnomeCanvas) is more complicated and has a higher overhead. > >This week I read that the widget item in gnome-canvas does not work very >well >http://blogs.gnome.org/view/alexl/2005/09/14/0 > >Steve > >Send instant messages to your online friends http://au.messenger.yahoo.com > > > >------------------------------------------------------- >SF.Net email is sponsored by: >Tame your development challenges with Apache's Geronimo App Server. Download >it for free - -and be entered to win a 42" plasma tv or your very own >Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >_______________________________________________ >Matplotlib-devel mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
|
From: Steve C. <ste...@ya...> - 2005-09-23 02:45:10
|
On Sun, 2005-09-18 at 16:45 -0400, Abraham Schneider wrote: > Currently matplotlib already draws its widgets on the canvas, so this > would allow a method to instead use native widgets in place of the > matplotlib widgets when possible. Using native widgets has the advantage > of response time and having a larger library at one's disposal. Even > without the mapping of matplotlib->native widgets, it can be useful to > easily put more controls to allow the plot to be altered (e.g. playing a > movie, rerunning a sim, etc.) This can also be accomplished (at least > with GTK) by adding another toolbar, but isn't always optimal. > > Is there an easy method to place widgets outside of the figure widget? Use the usual GTK+ widget placement methods - create a gtk.Window, add a VBox/HBox/Table etc and place the figure widget and other widgets in the container. This would be using the matplotlib OO interface like in examples/embedding_in_gtk2.py > Also, does this mean that matplotlib widgets should also not be drawn on > the canvas? Should matplotlib have turned itself into a widget library / GUI toolkit? I know that for a long time John resisted the temptation to add widgets to matplotlib and wanted matplotlib to focus on being a plotting library. I agree with this view and think the danger now is that matplotlib will become too big and bloated and harder to install (like the old SciPy?). I would prefer to see a 'matplotlib-core' which is a minimal module that focuses purely on plotting graphs. Other optional modules (like 'matplotlib-toolkits', 'matplotlib-widgets', etc) could then extend 'matplotlib-core' by providing extra features. > I checked on the link you gave, and it appears the problem occurs when > scrolling is involved. Currently with how things are done, I don't think > this will happen. Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: John H. <jdh...@ac...> - 2005-10-04 14:03:10
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> Should matplotlib have turned itself into a widget library
Steve> / GUI toolkit? I know that for a long time John resisted
Steve> the temptation to add widgets to matplotlib and wanted
Steve> matplotlib to focus on being a plotting library. I agree
Steve> with this view and think the danger now is that matplotlib
Steve> will become too big and bloated and harder to install (like
Steve> the old SciPy?).
Hey Steve,
If I'm not mistaken, the complexity of the core matplotlib build has
not changed in quite a while -- basically we've required zlib, png,
freetype and C++ since 0.5. Yes, some backends require additional
complexity (eg GTKAgg, the new WXAgg blit functionality) but you can
simply turn these options off in setup.py if you don't need them; in
the next few weeks I'm going to try and replace _gtkagg with pure
python using python buffers. All of the changes to support blitting,
widgets and so on have either been pure python or changes to existing
extension code (eg _backend_agg.cpp and _gtkagg.cpp). Also, the size
of the widgets module, which seems to bother you, is miniscule
> wc lib/matplotlib/widgets.py
985 3004 32510 lib/matplotlib/widgets.py
I don't want mpl to become a widget library. I did want to add some
support for controlling the subplot parameters, a very frequent gripe.
I could have say "dear backend maintainers, please add these sliders
and buttons to make this tool" and we would still be waiting.
I don't think any of the backends other than GTK* which I added have
implemented the resize functionality I requested on Sept 14th. That
doesn't really bother me too much, because I know people are busy with
other projects, but to the extent that I can get low level
functionality that lets the frontend do these things, I and others can
can roll out functionality that benefits almost all users much more
efficiently. I implemented sliders and buttons because I needed them.
They are pure python, took me less than a day, do something useful,
work out of the box across backends, and make up a small fraction of
the total code size. Looks like a win-win to me.
I implemented other widgets as an afterthought the same day as proof
of concept, with the thought that if someone wants to make a
*matplotlib tool* if they did it using the matplotlib widgets and
events it would immediately be available to everyone. Most GUI work
in python cannot be shared because it is tk specific, wx specific and
so on, and I wanted to find a way around this problem.
Steve> I would prefer to see a 'matplotlib-core' which is a
Steve> minimal module that focuses purely on plotting
Steve> graphs. Other optional modules (like 'matplotlib-toolkits',
Steve> 'matplotlib-widgets', etc) could then extend
Steve> 'matplotlib-core' by providing extra features.
I think the distinction between plotting and interacting with your
plot is not so clear. Sure, some small fraction of mpl users just
generate static graphs, but the majority I would guess actually use
things like matplotlib Events regularly (ie every time they use the
pan/zoom tools). Should these be addons, or part of the core?
I'm not opposed to this kind of packaging if it were done right (eg if
everyone had something roughly equivalent to debian's apt. I think
the vast majority of users want something that "just works". Nadia
has been working on pulling all of the non-matplotlib dependencies out
of the tree (CXX, Agg, png, zlib, pytz, dateutil) and revamping the
build system to grab a tarball off the internet if a configure system
doesn't detect them. This would make matplotlib CVS and the src
distro much ligher, which I'm sure all the developers who regularly do
CVS checkouts will appreciate since the damned pytz directories take
forever. This will definitely be a step in the right direction,
especially if we can get it to work across platforms.
As far as widgets are concerned, I don' think they can be placed in
an optional toolkit because the subplot tool requires them. At under
1000 lines of pure python, I also don't see the motivation. Contrast
this with basemap, which is over 10MB with lots of extension code. Or
would you like to see the toolbar and all of it's functionality rolled
into an option addon?
JDH
|
|
From: Steve C. <ste...@ya...> - 2005-10-09 01:42:03
|
On Tue, 2005-10-04 at 09:00 -0500, John Hunter wrote: > If I'm not mistaken, the complexity of the core matplotlib build has > not changed in quite a while -- basically we've required zlib, png, > freetype and C++ since 0.5. Yes, some backends require additional > complexity (eg GTKAgg, the new WXAgg blit functionality) but you can > simply turn these options off in setup.py if you don't need them; in > the next few weeks I'm going to try and replace _gtkagg with pure > python using python buffers. All of the changes to support blitting, > widgets and so on have either been pure python or changes to existing > extension code (eg _backend_agg.cpp and _gtkagg.cpp). Also, the size > of the widgets module, which seems to bother you, is miniscule > > > wc lib/matplotlib/widgets.py > 985 3004 32510 lib/matplotlib/widgets.py Once you have a GUI independent renderer and widget like backend_bases.RendererBase and FigureCanvasBase then you have the building blocks for writing a large GUI independent widget toolkit. But just because its possible does not mean you should do it. I can see that writing a small number of widgets is useful to mpl, but am concerned that it could easily snowball into a project that is not directly relevant to mpl. Abraham was suggesting that we provide a way to override these mpl widgets and use GTK widgets instead. I think that is unnecessary and undermines matplotlib's idea of using a GUI independent renderer and widget. Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: Eric F. <ef...@ha...> - 2007-01-06 19:23:23
|
Steve, Darren Dale raised a question offline that I think will be of general interest to mpl devels, and that you are the person to answer: How do you see the future of a cairo backend as a prospective replacement for most or all of the primary mpl backends? What would need to be completed in cairo? Based on the cairo web page, I get the impression that quite a bit is still missing, including eps generation and genuine vector ps. But maybe the web page is just out of date. What would need to be done in mpl, and how hard would it be? Would mpl get slower if everything went through cairo? Any other considerations? Thanks. Eric |
|
From: Steve C. <ste...@ya...> - 2007-01-07 08:44:16
|
On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote:
> Steve,
>
> Darren Dale raised a question offline that I think will be of general
> interest to mpl devels, and that you are the person to answer:
>
> How do you see the future of a cairo backend as a prospective
> replacement for most or all of the primary mpl backends?
I think cairo could potentially be used to replace the pdf, ps, svg
and gdk/gtk backends which would unify most of the backends and simplify
a lot of the code.
> What would need to be completed in cairo? Based on the cairo web page, I
> get the impression that quite a bit is still missing, including eps
> generation and genuine vector ps. But maybe the web page is just out of
> date.
Which web page is out of date? Where does it mention eps and ps, I
couldn't find it.
My general impression of the cairo "surfaces" is:
ImageSurface/png - support is very good
gtk/xlib - support is very good
ps/pdf/svg are usable but less mature and still developing so there may
be occasional problems drawing specific items
ps - it used to embed bitmap images but now most output is vector based
eps - is not supported yet, but may be in a future version
> What would need to be done in mpl, and how hard would it be?
The cairo backend can already be used for png, ps, pdf and gtk output so
I don't think there would be much to do. Mostly, it needs testing -
running all the mpl examples and checking the output looks OK.
> Would mpl get slower if everything went through cairo?
Not sure, you would need to run cairo and test it. It used to be much slower
than Agg but more recent versions have had many optimisations applied and
the difference is much smaller now.
> Any other considerations?
Some parts of mpl are Agg-specific and other parts (the whole drawing model)
are designed around the gdk drawing style - this makes things harder and
inefficient when using cairo.
On Sat, 2007-01-06 at 09:36 -1000, Eric Firing wrote:
> One more question: how does the image quality of cairo compare to
> Agg?
> Is the antialiasing as good?
Image quality looks OK to me, but I'm no expert.
The web browser Firefox 3.0 (due to be released early in 2007) will use
cairo for all rendering. Firefox requires a high level of graphics
performance and the upcoming cairo 1.4 release is expected to provide
that.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com
|
|
From: Eric F. <ef...@ha...> - 2007-01-06 19:36:57
|
Steve, One more question: how does the image quality of cairo compare to Agg? Is the antialiasing as good? Thanks. Eric |
|
From: John H. <jdh...@ac...> - 2007-01-08 16:10:33
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> My general impression of the cairo "surfaces" is:
Steve> ImageSurface/png - support is very good gtk/xlib - support
Steve> is very good ps/pdf/svg are usable but less mature and
Steve> still developing so there may be occasional problems
Steve> drawing specific items ps - it used to embed bitmap images
Steve> but now most output is vector based eps - is not supported
Steve> yet, but may be in a future version
This was my impression too - that it used to be raster PS but now uses
vector, but the web page seems to be claiming otherwise. In any case,
the LGPL/MPL (mozilla public license not to be confused with
matplotlib) seems to preclude our using it as our "core" renderer.
Unfortunately, Agg itself recently switched over to a GPL license, but
at least we have the 2.4 code base under BSD. We'll be in the same
position as enthought and a few other companies who are relying on the
BSD agg branch. At this state I think it advisable to make sure the
cairo backend stays up to snuff in case the agg situation eventually
becomes untenable, but agg is fairly stable and doesn't import
anything, event the C++ standard library, so 2.4 should be good for
some time to come. Hopefully the community (including us) will
maintain it.
Sigh,
JDH
|
|
From: Steve C. <ste...@ya...> - 2007-01-09 05:28:56
|
On Mon, 2007-01-08 at 10:09 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > Steve> My general impression of the cairo "surfaces" is: > Steve> ImageSurface/png - support is very good gtk/xlib - support > Steve> is very good ps/pdf/svg are usable but less mature and > Steve> still developing so there may be occasional problems > Steve> drawing specific items ps - it used to embed bitmap images > Steve> but now most output is vector based eps - is not supported > Steve> yet, but may be in a future version > > This was my impression too - that it used to be raster PS but now uses > vector, but the web page seems to be claiming otherwise. Which specific web page says otherwise? Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: Darren D. <dd...@co...> - 2007-01-08 16:25:19
|
Hi Steve, Eric, John,
On Sunday 07 January 2007 04:44, Steve Chaplin wrote:
> On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote:
> > Steve,
> >
> > Darren Dale raised a question offline that I think will be of general
> > interest to mpl devels, and that you are the person to answer:
> >
> > How do you see the future of a cairo backend as a prospective
> > replacement for most or all of the primary mpl backends?
>
> I think cairo could potentially be used to replace the pdf, ps, svg
> and gdk/gtk backends which would unify most of the backends and simplify
> a lot of the code.
This would really be a plus. The option to use latex for text layout would
have to be completely reworked, if it could be supported at all. Not that
this is a critical feature, but in my opinion it is still necessary at this
point for producing the highest quality plots for publication.
> > What would need to be completed in cairo? Based on the cairo web page, I
> > get the impression that quite a bit is still missing, including eps
> > generation and genuine vector ps. But maybe the web page is just out of
> > date.
>
> Which web page is out of date? Where does it mention eps and ps, I
> couldn't find it.
>
> My general impression of the cairo "surfaces" is:
> ImageSurface/png - support is very good
> gtk/xlib - support is very good
> ps/pdf/svg are usable but less mature and still developing so there may
> be occasional problems drawing specific items
> ps - it used to embed bitmap images but now most output is vector based
> eps - is not supported yet, but may be in a future version
>
> > What would need to be done in mpl, and how hard would it be?
>
> The cairo backend can already be used for png, ps, pdf and gtk output so
> I don't think there would be much to do. Mostly, it needs testing -
> running all the mpl examples and checking the output looks OK.
I had to alter the following lines from backend_gtkcairo, from
import matplotlib.backends.backend_cairo as be_cairo
from matplotlib.backends.backend_gtk import *
to
import backend_cairo as be_cairo
from backend_gtk import *
in order to prevent the following traceback:
Traceback (most recent call last):
File "/usr/bin/ipython", line 27, in ?
IPython.Shell.start().mainloop()
File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in
start
return shell(user_ns = user_ns)
File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in
__init__
shell_class=MatplotlibMTShell)
File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in
__init__
on_kill=[mainquit])
File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in
make_IPython
embedded=embedded,**kw)
File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in
__init__
user_ns,b2 = self._matplotlib_config(name,user_ns)
File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in
_matplotlib_config
from matplotlib import backends
File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
line 55, in ?
new_figure_manager, draw_if_interactive, show = pylab_setup()
File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
line 23, in pylab_setup
globals(),locals(),[backend_name])
File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
line 11, in ?
import matplotlib.backends.backend_cairo as be_cairo
AttributeError: 'module' object has no attribute 'backends'
I only had a short time to work with backend_gtkcairo, but a couple of things
caught my attention. mathtext support seemed to need some improvement, it
looked like it was rendered as an image rather than as text. Also,
imshow(rand(100,100)) looked very different with gtkcairo and gtkagg, (maybe
because the rgba ordering is different in agg and cairo? I'm not sure this is
even the case, I'm taking a stab in the dark.)
> > Would mpl get slower if everything went through cairo?
>
> Not sure, you would need to run cairo and test it. It used to be much
> slower than Agg but more recent versions have had many optimisations
> applied and the difference is much smaller now.
>
> > Any other considerations?
>
> Some parts of mpl are Agg-specific and other parts (the whole drawing
> model) are designed around the gdk drawing style - this makes things harder
> and inefficient when using cairo.
I'm just thinking out loud here, brainstorming, but may be getting completely
ahead of myself. Feel free to tell me so. If we made a mpl-pre1.0 branch, and
reconstructed the drawing model, how much work are we talking about? Since
gtk includes cairo now, couldn't a single gtk backend replace both gtk and
gtkagg, while retaining the speed of the pure gtk backend?
> On Sat, 2007-01-06 at 09:36 -1000, Eric Firing wrote:
> > One more question: how does the image quality of cairo compare to
> > Agg?
> > Is the antialiasing as good?
>
> Image quality looks OK to me, but I'm no expert.
>
> The web browser Firefox 3.0 (due to be released early in 2007) will use
> cairo for all rendering. Firefox requires a high level of graphics
> performance and the upcoming cairo 1.4 release is expected to provide
> that.
|
|
From: Nicholas Y. <mat...@su...> - 2007-01-08 16:51:53
|
Darren Dale wrote: > Hi Steve, Eric, John, > On Sunday 07 January 2007 04:44, Steve Chaplin wrote: >> On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote: >>> How do you see the future of a cairo backend as a prospective >>> replacement for most or all of the primary mpl backends? >> I think cairo could potentially be used to replace the pdf, ps, svg >> and gdk/gtk backends which would unify most of the backends and simplify >> a lot of the code. > > This would really be a plus. The option to use latex for text layout would > have to be completely reworked, if it could be supported at all. Not that > this is a critical feature, but in my opinion it is still necessary at this > point for producing the highest quality plots for publication. Playing around with using Cairo for something else, I once wrote some code to convert dvi to Cairo. The code I wrote probably isn't suitable for use by matplotlib, but it wasn't particularly difficult to write. The most difficult thing was finding the correct fonts - but I know people on this list have a lot of experience with that kind of problem anyway. It is possible the code would need to be in c/c++ for speed - my code was anyway so I don't know. I would offer to write something myself, but I'm leaving the field in which I use matplotlib around now and I wouldn't be able to maintain anything I wrote. Nicholas |
|
From: Darren D. <dd...@co...> - 2007-01-08 19:15:55
|
On Monday 08 January 2007 11:51, Nicholas Young wrote: > Darren Dale wrote: > > Hi Steve, Eric, John, > > > > On Sunday 07 January 2007 04:44, Steve Chaplin wrote: > >> On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote: > >>> How do you see the future of a cairo backend as a prospective > >>> replacement for most or all of the primary mpl backends? > >> > >> I think cairo could potentially be used to replace the pdf, ps, svg > >> and gdk/gtk backends which would unify most of the backends and simplify > >> a lot of the code. > > > > This would really be a plus. The option to use latex for text layout > > would have to be completely reworked, if it could be supported at all. > > Not that this is a critical feature, but in my opinion it is still > > necessary at this point for producing the highest quality plots for > > publication. > > Playing around with using Cairo for something else, I once wrote some > code to convert dvi to Cairo. The code I wrote probably isn't suitable > for use by matplotlib, but it wasn't particularly difficult to > write. The most difficult thing was finding the correct fonts - but I > know people on this list have a lot of experience with that kind of > problem anyway. It is possible the code would need to be in c/c++ for > speed - my code was anyway so I don't know. > > I would offer to write something myself, but I'm leaving the field in > which I use matplotlib around now and I wouldn't be able to maintain > anything I wrote. Would you be willing to contribute this code to mpl? If so, please forward it to me off list. I would really like to have a look. Darren |
|
From: John H. <jdh...@ac...> - 2007-01-08 17:00:53
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes:
Darren> This would really be a plus. The option to use latex for
Darren> text layout would have to be completely reworked, if it
Darren> could be supported at all. Not that this is a critical
Darren> feature, but in my opinion it is still necessary at this
Darren> point for producing the highest quality plots for
Darren> publication.
For many people this is absolutely the killer feature of mpl
JDH
|
|
From: John H. <jdh...@ac...> - 2007-01-08 17:04:15
|
>>>>> "John" == John Hunter <jdh...@ac...> writes:
>>>>> "Darren" == Darren Dale <dd...@co...> writes:
Darren> This would really be a plus. The option to use latex for
Darren> text layout would have to be completely reworked, if it
Darren> could be supported at all. Not that this is a critical
Darren> feature, but in my opinion it is still necessary at this
Darren> point for producing the highest quality plots for
Darren> publication.
John> For many people this is absolutely the killer feature of mpl
But I should add if cairo the cairo ps backend had good image support,
we could put 6000 dpi images into the ps backend for the latex
mathtext which would be fine.
JDH
|
|
From: Darren D. <dd...@co...> - 2007-01-08 20:23:53
|
On Monday 08 January 2007 12:02, John Hunter wrote: > >>>>> "John" == John Hunter <jdh...@ac...> writes: > >>>>> > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> This would really be a plus. The option to use latex for > Darren> text layout would have to be completely reworked, if it > Darren> could be supported at all. Not that this is a critical > Darren> feature, but in my opinion it is still necessary at this > Darren> point for producing the highest quality plots for > Darren> publication. > > John> For many people this is absolutely the killer feature of mpl > > But I should add if cairo the cairo ps backend had good image support, > we could put 6000 dpi images into the ps backend for the latex > mathtext which would be fine. On the other hand, you would then lose the ability to search a pdf file for text in the figures. This is currently only possible using by setting ps.usedistiller to "xpdf", but it is a really nice feature. |
|
From: Eric F. <ef...@ha...> - 2007-01-09 06:15:50
|
Steve Chaplin wrote: > On Mon, 2007-01-08 at 10:09 -0600, John Hunter wrote: >>>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: >> Steve> My general impression of the cairo "surfaces" is: >> Steve> ImageSurface/png - support is very good gtk/xlib - support >> Steve> is very good ps/pdf/svg are usable but less mature and >> Steve> still developing so there may be occasional problems >> Steve> drawing specific items ps - it used to embed bitmap images >> Steve> but now most output is vector based eps - is not supported >> Steve> yet, but may be in a future version >> >> This was my impression too - that it used to be raster PS but now uses >> vector, but the web page seems to be claiming otherwise. > Which specific web page says otherwise? http://cairographics.org/backends It looks like this simply has not been kept up to date. Eric |
|
From: Steve C. <ste...@ya...> - 2007-01-10 10:29:49
|
On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > > > What would need to be done in mpl, and how hard would it be? > > > > The cairo backend can already be used for png, ps, pdf and gtk output so > > I don't think there would be much to do. Mostly, it needs testing - > > running all the mpl examples and checking the output looks OK. > > I had to alter the following lines from backend_gtkcairo, from > > import matplotlib.backends.backend_cairo as be_cairo > from matplotlib.backends.backend_gtk import * > > to > > import backend_cairo as be_cairo > from backend_gtk import * > > in order to prevent the following traceback: > > Traceback (most recent call last): > File "/usr/bin/ipython", line 27, in ? > IPython.Shell.start().mainloop() > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in > start > return shell(user_ns = user_ns) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in > __init__ > shell_class=MatplotlibMTShell) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in > __init__ > on_kill=[mainquit]) > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in > make_IPython > embedded=embedded,**kw) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in > __init__ > user_ns,b2 = self._matplotlib_config(name,user_ns) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in > _matplotlib_config > from matplotlib import backends > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > line 55, in ? > new_figure_manager, draw_if_interactive, show = pylab_setup() > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > line 23, in pylab_setup > globals(),locals(),[backend_name]) > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py", > line 11, in ? > import matplotlib.backends.backend_cairo as be_cairo > AttributeError: 'module' object has no attribute 'backends' The original matplotlib code is correct, you should be editing IPython and correcting their bug! Matplotlib does use a lot of relative imports which I think is bad style. See PEP 8 "Style Guide for Python Code" http://www.python.org/dev/peps/pep-0008/ - Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports. Even now that PEP 328 [7] is fully implemented in Python 2.5, its style of explicit relative imports is actively discouraged; absolute imports are more portable and usually more readable. There was a recent "Coding Guide" thread on this list (which I admit I just skimmed through). Instead of reinventing the wheel, how about stating at the top of CODING_GUIDE that PEP 8 is the default style for matplotlib, and the following notes give in-depth matplotlib examples (or possibly override PEP 8 if necessary). Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: John H. <jdh...@ac...> - 2007-01-10 17:56:42
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> Matplotlib does use a lot of relative imports which I think
Steve> is bad style.
Steve> See PEP 8 "Style Guide for Python Code"
Steve> http://www.python.org/dev/peps/pep-0008/
Steve> - Relative imports for intra-package imports are highly
Steve> discouraged. Always use the absolute package path for all
Steve> imports. Even now that PEP 328 [7] is fully implemented in
Steve> Python 2.5, its style of explicit relative imports is
Steve> actively discouraged; absolute imports are more portable
Steve> and usually more readable.
I have never run into a problem with relative imports, though I don't
object to removing them. Why are they bad style and what is the danger?
Steve> There was a recent "Coding Guide" thread on this list
Steve> (which I admit I just skimmed through). Instead of
Steve> reinventing the wheel, how about stating at the top of
Steve> CODING_GUIDE that PEP 8 is the default style for
Steve> matplotlib, and the following notes give in-depth
Steve> matplotlib examples (or possibly override PEP 8 if
Steve> necessary).
Agreed -- I'll update the coding style section to refer to this
document, and provide a few comments in line.
JDH
|
|
From: Matthew B. <mat...@gm...> - 2007-01-10 20:36:20
|
> I have never run into a problem with relative imports, though I don't > object to removing them. Why are they bad style and what is the danger? I had assumed because it would not be as obvious that the imports were local modules, but might be wrong... Best, Matthew |
|
From: Steve C. <ste...@ya...> - 2007-01-11 05:56:04
|
On Wed, 2007-01-10 at 11:55 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> Matplotlib does use a lot of relative imports which I think > Steve> is bad style. > > Steve> See PEP 8 "Style Guide for Python Code" > Steve> http://www.python.org/dev/peps/pep-0008/ > > Steve> - Relative imports for intra-package imports are highly > Steve> discouraged. Always use the absolute package path for all > Steve> imports. Even now that PEP 328 [7] is fully implemented in > Steve> Python 2.5, its style of explicit relative imports is > Steve> actively discouraged; absolute imports are more portable > Steve> and usually more readable. > > I have never run into a problem with relative imports, though I don't > object to removing them. Why are they bad style and what is the danger? Its because you can unwittingly end up with module name clashes. There can be two different modules in two different directories with the same name and you import the wrong module by mistake. It happened to me once when I created a 'calendar.py' module and didn't realize that Python already has a calendar module. Its hard to debug because you get a traceback which makes no sense. >From PEP328 http://www.python.org/dev/peps/pep-0328/ Rationale for Absolute Imports In Python 2.4 and earlier, if you're reading a module located inside a package, it is not clear whether import foo refers to a top-level module or to another module inside the package. As Python's library expands, more and more existing package internal modules suddenly shadow standard library modules by accident. It's a particularly difficult problem inside packages because there's no way to specify which module is meant. To resolve the ambiguity, it is proposed that foo will always be a module or package reachable from sys.path. This is called an absolute import. Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: Peter W. <pw...@en...> - 2007-01-11 15:14:44
|
On Jan 11, 2007, at 12:55 AM, Steve Chaplin wrote:
>> I have never run into a problem with relative imports, though I don't
>> object to removing them. Why are they bad style and what is the
>> danger?
>
> Its because you can unwittingly end up with module name clashes. There
> can be two different modules in two different directories with the
> same
> name and you import the wrong module by mistake.
Just wanted to chime in here --
with python 2.5, you can have your cake and eat it too:
from .localpkg import Symbol1, Symbol2
from . import localpkg
This disambiguates the "calendar.py" problem that you had (and that
about 90% of python coders have had at least once in their lives). :)
-Peter
|
|
From: Fernando P. <fpe...@gm...> - 2007-01-11 07:01:22
|
On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
> > I had to alter the following lines from backend_gtkcairo, from
> >
> > import matplotlib.backends.backend_cairo as be_cairo
> > from matplotlib.backends.backend_gtk import *
> >
> > to
> >
> > import backend_cairo as be_cairo
> > from backend_gtk import *
> >
> > in order to prevent the following traceback:
> >
> > Traceback (most recent call last):
> > File "/usr/bin/ipython", line 27, in ?
> > IPython.Shell.start().mainloop()
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in
> > start
> > return shell(user_ns = user_ns)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in
> > __init__
> > shell_class=MatplotlibMTShell)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in
> > __init__
> > on_kill=[mainquit])
> > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in
> > make_IPython
> > embedded=embedded,**kw)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in
> > __init__
> > user_ns,b2 = self._matplotlib_config(name,user_ns)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in
> > _matplotlib_config
> > from matplotlib import backends
> > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > line 55, in ?
> > new_figure_manager, draw_if_interactive, show = pylab_setup()
> > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > line 23, in pylab_setup
> > globals(),locals(),[backend_name])
> >
> > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
> > line 11, in ?
> > import matplotlib.backends.backend_cairo as be_cairo
> > AttributeError: 'module' object has no attribute 'backends'
>
> The original matplotlib code is correct, you should be editing IPython
> and correcting their bug!
Well, I'd be delighted to correct the ipython bug, if only I
understood exactly what the problem was... As far as I can see, that
code in ipython is simply calling
# Initialize matplotlib to interactive mode always
import matplotlib
from matplotlib import backends
inside a function (the _matplotlib_config method). I don't see a bug
in that, but if you provide some pointers, I'll be happy to fix any
issues that are on ipython's side of the fence.
Cheers,
f
|
|
From: Steve C. <ste...@ya...> - 2007-01-11 14:08:30
|
On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > I only had a short time to work with backend_gtkcairo, but a couple of things > caught my attention. mathtext support seemed to need some improvement, it > looked like it was rendered as an image rather than as text. Also, > imshow(rand(100,100)) looked very different with gtkcairo and gtkagg, (maybe > because the rgba ordering is different in agg and cairo? I'm not sure this is > even the case, I'm taking a stab in the dark.) cairo mathtext uses a method copied from gdk/gtk and does render an image. It needs updating to render text. imshow does look different on cairo and agg, and yes, It looks like an image format problem. cairo uses ARGB32 with pre-multiplied alpha, and the ARGB order depends on whether the machine is little- of big-endian. Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: John H. <jdh...@ac...> - 2007-01-11 14:43:02
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes:
Darren> I had to alter the following lines from backend_gtkcairo,
Darren> from
Darren> import matplotlib.backends.backend_cairo as be_cairo from
Darren> matplotlib.backends.backend_gtk import *
Darren> "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
Darren> line 11, in ? import matplotlib.backends.backend_cairo as
Darren> be_cairo AttributeError: 'module' object has no attribute
Darren> 'backends'
My guess is that you were running your test code in which there was a
"matplotlib" dir that was not *the* matplotlib install dir.
Possible?
JDH
|
Thanks for helping keep SourceForge clean.
X