(The quoting got screwed in my previous post, so I'm re-posting it.
Sorry about that.)
On Wed, Nov 17, 2010 at 6:30 PM, Michiel de Hoon <mjldehoon@...> 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 <mjldehoon@...> 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
|