On Wed, Nov 17, 2010 at 6:30 PM, Michiel de Hoon <mjldeh...@yahoo.com>wrote:
> In principle the non-interactive mode can also be implemented in this
> backend. If that would solve your problem, could you open a bug report for
> it?
>
>
How??? I feel so inept: I can't even find matplotlib's bug
reporting/tracking page! Is there one? If so, it is well hidden. All I
was able to find was
http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html?highlight=bug#reporting-problems
which basically says to send an email to the matplotlib list. But didn't I
just do this already? I'm confused.
On Thu, Nov 18, 2010 at 8:06 PM, Michiel de Hoon <mjldeh...@yahoo.com>wrote:
If you use the MacOSX backend, you won't need pygtk, pycairo, pyqt,
pygobject, wx, tcl/tk, or anything they depend on, which was my main
motivation for writing this backend. Other than the fact that the MacOSX
backend currently does not support the non-interactive mode, it should work
for you, doesn't it?
Actually, getting the non-interactive behavior was the reason I was trying
to install a backend different from the MacOSX one. As I described in an
earlier post, I want to simulate a perfect separation between the creation
and manipulation of graphic objects, and their output (either in a graphical
display or by saving them to a file). In other words, with this simulation
in place, one should be able to create graphical objects, translate them,
scale them, shear them, recombine them, split them up, interrogate them,
etc., and finally save these objects to files, without a window ever popping
up. In fact, this code should run perfectly well on a terminal without
any graphical capabilities at all.
Incidentally, one of the reasons for my difficulties with using matplotlib
is 100% conceptual. I just can't wrap my head around the idea of needing to
implement a "non-interactive" mode. (Actually, I to call it "non-GUI",
since it's perfectly possible to envision an interaction that is entirely
text-based.) In my brain, such "non-GUI" mode is the default behavior,
because, as I described above, the creation and manipulation of graphic
objects logically precedes and is conceptually independent of their output.
Therefore, the absolutely simplest system for dealing with such graphic
objects would have no output at all: the user would (either through a
script, or interactively, through a text-based interface) create and
manipulate graphics objects that live in memory and disappear when the
process/session is terminated. Of course, the usefulness of such a system
would be very limited, but it would certainly be my first step. Only after
that I would implement the various ways to output the graphical objects.
This is the only ordering of capabilities that makes sense to me.
When I read your message about implementing the non-GUI mode, it turns this
simple picture completely on its head, which tells me that matplotlib's
architecture is, at this point, beyond my comprehension. One of the reasons
for looking forward to your implementation of the non-GUI mode for the
MacOSX backend is that, by studying a diff between this enhanced version and
the previous version I may be able to finally understand matplotlib's basic
architecture.
~kj
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
