Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

[Kynn Jones]

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

[matplotlib-devel] How to decouple non-GUI stuff from the GUI?

[Kynn Jones]

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

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

[John Hunter]

On Fri, Nov 19, 2010 at 9:10 AM, Kynn Jones  wrote:

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

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

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

[John Hunter]

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

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

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

[Benjamin Root]

On Fri, Nov 19, 2010 at 9:19 AM, John Hunter  wrote:

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

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

[Christopher Barker]

> 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



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

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

[Kynn Jones]

On Fri, Nov 19, 2010 at 10:15 AM, John Hunter  wrote:
> On Fri, Nov 19, 2010 at 9:10 AM, Kynn Jones  wrote:
>> On Wed, Nov 17, 2010 at 6:30 PM, Michiel de Hoon  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,
>   but it is a good idea to ping us on the mailing list too.

Thanks!  I added the bug report:

https://sourceforge.net/tracker/?func=detail&aid=3113191&group_id=80706&atid=560720

~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

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

[Kynn Jones]

On Fri, Nov 19, 2010 at 5:08 PM, Christopher Barker
 wrote:
> "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.

Thanks, this is a very helpful clarification.

~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