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