matplotlib-devel Mailing List for matplotlib

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

This is exactly what the non-gui back-ends are for (agg in particular).

While it would be nice to be able to do all that with a GUI back-end, 
the point of the GUI is to give you a GUI -- if you don't need one, 
don't use one.

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

non-GUI is what the Agg, etc back-ends are for. non-interactive is a 
different concept -- it's specifically a subset of GUI behavior:

"interactive" means that you are typing things interactively at the 
command prompt, and thus want to see changes you make to a figure after 
each change -- exactly the opposite of what you want.

"non-interactive" means that you want to be able to do a number of 
manipulations to a figure, and only show the result of those changes 
when you specifically ask to see them. This is kind of similar to what 
you want, but till really talking about behavior with a GUI back-end.

non-GUI back ends are inherently non-interactive.

I'm not totally sure about how MPL works, but it may need to query teh 
back-end occasinally when doing layout, etc. That may require the GUI 
toolkit to be initialized even before anyactual rendering is done. If 
that's the case, then you simpily never want to use a GUI back-end when 
you don't have/need a GUI (text terminal, web application, batch 
scripts, etc).

-Chris

On Fri, Nov 19, 2010 at 9:19 AM, John Hunter <jd...@gm...> wrote:

> On Fri, Nov 19, 2010 at 9:10 AM, Kynn Jones <ky...@gm...> wrote:
> >
> >
> > 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.
> >
>
> >From the introduction: http://matplotlib.sourceforge.net/users/intro.html
> ::
>
>  The matplotlib code is conceptually divided into three parts: the
>  pylab interface is the set of functions provided by matplotlib.pylab
>  which allow the user to create plots with code quite similar to
>  MATLAB figure generating code (Pyplot tutorial). The matplotlib
>  frontend or matplotlib API is the set of classes that do the heavy
>  lifting, creating and managing figures, text, lines, plots and so on
>  (Artist tutorial). This is an abstract interface that knows nothing
>  about output. The backends are device dependent drawing devices, aka
>  renderers, that transform the frontend representation to hardcopy or
>  a display device (What is a backend?). Example backends: PS creates
>  PostScript? hardcopy, SVG creates Scalable Vector Graphics hardcopy,
>  Agg creates PNG output using the high quality Anti-Grain Geometry
>  library that ships with matplotlib, GTK embeds matplotlib in a Gtk+
>  application, GTKAgg uses the Anti-Grain renderer to create a figure
>  and embed it a Gtk+ application, and so on for PDF, WxWidgets,
>  Tkinter etc.
>
>  matplotlib is used by many people in many different contexts. Some
>  people want to automatically generate PostScript files to send to a
>  printer or publishers. Others deploy matplotlib on a web application
>  server to generate PNG output for inclusion in dynamically-generated
>  web pages. Some use matplotlib interactively from the Python shell
>  in Tkinter on Windows?. My primary use is to embed matplotlib in a
>  Gtk+ EEG application that runs on Windows, Linux and Macintosh OS X.
>
>
>
> Elaborating a little bit: the middle part of matplotlib, the artist
> hierarchy, is what I think you are looking for.  That is where
> abstractions like Line2D, Circle and Text live.  There is no concept
> of a GUI or a render at that abstraction.
>
> http://matplotlib.sourceforge.net/users/artists.html#artist-tutorial
>
>
Exactly, this is the part of matplotlib that Kynn should focus on -- as a
hierarchy of artist objects.  I do think that Kynn would have a somewhat
valid argument with regards to how matplotlib is presented, though.  For
example, the pylab interface is completely "magical" and utterly bypasses
any object-oriented-ness.  Then, the pyplot interface (which I use most of
the time) provides a more OOP-esque interface.  However, the documentation
and examples for the plotting functions do not emphasize the fact that they
return graphing objects, mostly because they get automatically attached to
the axes object and it is unnecessary to do anything with those objects.
Usually, users just let the functions return those objects without an
assignment to anywhere.

While I think pyplot strikes the right balance (for me), I often wonder if
the way this interface is presented causes a logical hinderance to fully
understanding the final layer of the graphical artist objects and
collections.  Because the underlying graphical objects are typically ignored
by the users and handled automatically, this layer doesn't receive as much
developer attention to make it more versatile and complete.

Just my 2 cents on this issue.  Actual value of the thought varies based
upon the current value of the dollar in your area...

Ben Root

On Fri, Nov 19, 2010 at 9:10 AM, Kynn Jones <ky...@gm...> wrote:
>
>
> 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.
>

>From the introduction: http://matplotlib.sourceforge.net/users/intro.html::

  The matplotlib code is conceptually divided into three parts: the
  pylab interface is the set of functions provided by matplotlib.pylab
  which allow the user to create plots with code quite similar to
  MATLAB figure generating code (Pyplot tutorial). The matplotlib
  frontend or matplotlib API is the set of classes that do the heavy
  lifting, creating and managing figures, text, lines, plots and so on
  (Artist tutorial). This is an abstract interface that knows nothing
  about output. The backends are device dependent drawing devices, aka
  renderers, that transform the frontend representation to hardcopy or
  a display device (What is a backend?). Example backends: PS creates
  PostScript? hardcopy, SVG creates Scalable Vector Graphics hardcopy,
  Agg creates PNG output using the high quality Anti-Grain Geometry
  library that ships with matplotlib, GTK embeds matplotlib in a Gtk+
  application, GTKAgg uses the Anti-Grain renderer to create a figure
  and embed it a Gtk+ application, and so on for PDF, WxWidgets,
  Tkinter etc.

  matplotlib is used by many people in many different contexts. Some
  people want to automatically generate PostScript files to send to a
  printer or publishers. Others deploy matplotlib on a web application
  server to generate PNG output for inclusion in dynamically-generated
  web pages. Some use matplotlib interactively from the Python shell
  in Tkinter on Windows?. My primary use is to embed matplotlib in a
  Gtk+ EEG application that runs on Windows, Linux and Macintosh OS X.



Elaborating a little bit: the middle part of matplotlib, the artist
hierarchy, is what I think you are looking for.  That is where
abstractions like Line2D, Circle and Text live.  There is no concept
of a GUI or a render at that abstraction.

http://matplotlib.sourceforge.net/users/artists.html#artist-tutorial

On Fri, Nov 19, 2010 at 9:10 AM, Kynn Jones <ky...@gm...> wrote:

>  On Wed, Nov 17, 2010 at 6:30 PM, Michiel de Hoon <mjl...@ya...>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
>
>

Take a look at the home page http://matplotlib.sourceforge.net on the right
panel there is a box with the title "Need help?" which says :

  You can file bugs, patches and feature requests on the sourceforge
tracker<http://sourceforge.net/tracker2/?group_id=80706>,

  but it is a good idea to ping us on the mailing list too.

Sorry this has been so difficult and confusing.  I think you will save
yourself a lot of pain by using the Enthought Python Distribution I pointed
you too.  There is a free academic version as well as a trial version.

JDH

(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 <mjl...@ya...> 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 <mjl...@ya...> 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

 On Wed, Nov 17, 2010 at 6:30 PM, Michiel de Hoon <mjl...@ya...>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 <mjl...@ya...>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

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?

--Michiel.

--- On Thu, 11/18/10, Kynn Jones <ky...@gm...> wrote:

From: Kynn Jones <ky...@gm...>
Subject: Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?
To: mat...@li...
Date: Thursday, November 18, 2010, 5:11 PM

On Wed, Nov 17, 2010 at 6:33 PM, Benjamin Root <ben...@ou...> wrote:


As an additional note, if you are having difficulty compiling for MacOS X, why not just ask for help with that?

Just to keep from ranting like a lunatic, basically.  The experience was traumatic enough to shake my faith in Python altogether, and made me miss good ol' CPAN.

To summarize 2-3 day's worth of frustration:
1.
GTK, GTKAgg:ImportError: Gtk* backend requires pygtk to be installed.

GTKCairo:ImportError: No module named backend_gtkcairo
FltkAgg:ImportError: No module named fltk
QtAgg:ImportError: Qt backend requires pyqt to be installed.

Qt4Agg:ImportError: Warning: formlayout requires PyQt4 >v4.3
WX, WXAgg:ImportError: Matplotlib backend_wx and backend_wxagg require wxPython >=2.8


2. configuration of pygtk fails:
checking for PYGOBJECT... configure: error: Package requirements (pygobject-2.0 >= 2.21.3) were not met:

No package 'pygobject-2.0' found

3. configuration of pygobject fails:
checking for PYCAIRO... configure: error: Package requirements (pycairo >= 1.0.2
        ) were not met:
No package 'pycairo' found

4. installation of pycairo fails (after > 6 hours of trying a variety of approaches); currently, importing cairo produces a fatal error:

% pythonPython 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) [GCC 4.2.1 (Apple Inc. build 5646)] on darwinType "help", "copyright", "credits" or "license" for more information.
>>> import cairoFatal Python error: Interpreter not initialized (version mismatch?)zsh: abort      python

By this point, I just gave up on getting any more interactive backends for matplotlib.  (I reiterate that the above is a barebone's summary.  There's a lot that I'm omitting.)

As an aside, I have never in my life seen a worse installation system than pycairo's.  If you have not examined it in detail, please do so before reacting to my comments.  In particular look at the waf file, and the files it invokes.  Also, when you find the latter, do a global search for the number 1337 to get a whiff pycairo's excremental aroma.

There is no point in choosing Python as one's programming language if this means that one depends on garbage like pycairo.  I think it is unfair to put unsuspecting users of matplotlib through the ordeal of dealing with pycairo's installation.  (And pygtk's and pygobjects's are not much better.)  We can't force people to write good Python, but at the very least we should not propagate bad code.  Packages like pycairo, pygtk, and pygobjects are substandard, and they should be ostracized by the rest of the Python community until they shape up.

Even putting pycairo aside, the Python package installation system is a disaster.  The problems I've summarized on this page are par for the course with Python packages.  Just getting matplotlib to install (even without most interactive backends) was also a multi-day nightmare...

You see?  I'm ranting like a lunatic.  Sorry.  I'll stop.
~kj


-----Inline Attachment Follows-----

------------------------------------------------------------------------------
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
-----Inline Attachment Follows-----

_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



      

On 11/18/10 3:08 PM, John Hunter wrote:
> Yes, installing these GUIs on OSX is a mess, particularly GTK.  I only
> recommend it for the very brave and foolish.

yup -- though wxPython is trivial.

Do make sure you're running the python.org python, though -- that's the 
one most likely to be supported by various binary packages.

>  If you use the enthought
> python distribution for OSX, you should get a working tkagg, qt4agg,
> wxagg and macosx (I think)

I don't know if enthought is worth it for that -- but it sure is if you 
want VTK. Mayavi, and a few other really ugly packages!

As for the wonders of CPAN:

I've never been a perl user, but the issues with packages like 
matplotlib on OS-X are due to compiled code that depends on libraries 
that aren't delivered with the OS, on an OS that can have up to four 
diffferent hardware architectures, and a pretty rapidly changing API (or 
ABI anyway). Oh, and it depends on various GUI toolkits that have those 
same issues.

I can't imagine how a CPAN-like system would help with that at all. 
Installing pure python packages isn't a problem at all.

-Chris


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

Chr...@no...