Auto backend discovery at start time

Hello guys!
Following up the discussion Benjiamin and me had about a couple of
bugs in Ubuntu[1] and Debian[2], and what Mike wrote on [1], we'd like
to explore the possibility for you to develop a "backend=Auto" mode,
that can discover automatically at runtime the backend to use from the
ones available (in case of multiple backends, let's use a priority
list [gtk, qt, tk, ...]).

Our main goal, as packagers, is to avoid the installation of gnome
dependencies (gtk2 is now the default in both sid and
lenny-near-to-be-stable, for Ubuntu is tk) for kde users (and
viceversa, or any other combination).

One way is to ship a "core" package, that contains the main
functionalities, and some "backend" packages to depends (or even
contains the real backend files, like .so & altera) on the available
gui python bindings.

Related to the above sentence, is this question: how easy is to
"split" backend files? is it enough to separate files under
/usr/lib/python*/site-packages/matplotlib/backends/* in different
packages? But that would only create 3 pkgs: agg, gtk and tk. What
about wx and qt?

Personally, I think we can even attack the problem with a different
solution: continue to ship all the mpl file in the "main" package
(python-matplotlib in Debian & Ubuntu) and then create some "dummy"
packages that simply depends on the python gui bindings (let's call
them python-matplotlib-≤ui>), each of them providing a virtual
package, let's call it python-matplotlib-backend. If python-matplotlib

Please test this patch on windows...

Index: lib/matplotlib/__init__.py
===================================================================
--- lib/matplotlib/__init__.py	(revision 6360)
+++ lib/matplotlib/__init__.py	(working copy)
@@ -93,8 +93,9 @@
 __revision__ = '$Revision$'
 __date__     = '$Date$'

-import os, re, shutil, sys, warnings
+import os, re, shutil, subprocess, sys, warnings
 import distutils.sysconfig
+import distutils.version

 
 NEWCONFIG = False
@@ -256,10 +257,10 @@

 def checkdep_dvipng():
     try:
-        stdin, stdout = os.popen4('dvipng -version')
-        line = stdout.readlines()[1]
+        s = subprocess.Popen(['dvipng','-version'], stdout=subprocess.PIPE,
+                             stderr=subprocess.PIPE)
+        line = s.stdout.readlines()[1]
         v = line.split()[-1]
-        float(v)
         return v
     except (IndexError, ValueError):
         return None
@@ -267,47 +268,45 @@
 def checkdep_ghostscript():
     try:
         if sys.platform == 'win32':
-            command = 'gswin32c --version'
+            command_args = ['gswin32c', '--version']
         else:
-            command = 'gs --version'
-        stdin, stdout = os.popen4(command)
-        v = stdout.read()[:-1]
-        vtest = '.'.join(v.split('.')[:2]) # deal with version numbers like '7.07.1'
-        float(vtest)
-        return vtest
+            command_args = ['gs', '--version']
+        s = subprocess.Popen(command_args, stdout=subprocess.PIPE,
+                             stderr=subprocess.PIPE)
+        v = s.stdout.read()[:-1]
+        return v
     except (IndexError, ValueError):
         return None

 def checkdep_tex():
     try:
-        stdin, stdout = os.popen4('tex -version')
-        line = stdout.readlines()[0]
+        s = subprocess.Popen(['tex','-version'], stdout=subprocess.PIPE,
+                             stderr=subprocess.PIPE)
+        line = s.stdout.readlines()[0]
         pattern = '3\.1\d+'
         match = re.search(pattern, line)
         v = match.group(0)
-        float(v)
         return v
     except (IndexError, ValueError, AttributeError):
         return None

 def checkdep_pdftops():
     try:
-        stdin, stdout = os.popen4('pdftops -v')
-        for line in stdout.readlines():
+        s = subprocess.Popen(['pdftops','-v'], stdout=subprocess.PIPE,
+                             stderr=subprocess.PIPE)
+        for line in s.stderr:
             if 'version' in line:
                 v = line.split()[-1]
-        float(v)
         return v
     except (IndexError, ValueError, UnboundLocalError):
         return None

 def compare_versions(a, b):
-    "return True if a is greater than b"
+    "return True if a is greater than or equal to b"
     if a:
-        a = [int(i) for i in a.split('.')]
-        b = [int(i) for i in b.split('.')]
-        if a[0]>b[0]: return True
-        elif (a[0]==b[0]) and (a[1]>=b[1]): return True
+        a = distutils.version.LooseVersion(a)
+        b = distutils.version.LooseVersion(b)
+        if a>=b: return True
         else: return False
     else: return False

@@ -330,8 +329,13 @@

     if s == 'xpdf':
         pdftops_req = '3.0'
+        pdftops_req_alt = '0.9' # poppler version numbers, ugh
         pdftops_v = checkdep_pdftops()
-        if compare_versions(pdftops_v, pdftops_req): pass
+        if compare_versions(pdftops_v, pdftops_req):
+            pass
+        elif compare_versions(pdftops_v, pdftops_req_alt) and not \
+            compare_versions(pdftops_v, '1.0'):
+            pass
         else:
             flag = False
             warnings.warn(('matplotlibrc ps.usedistiller can not be set to '

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

Re: Auto backend discovery at start time

On Sat, Nov 1, 2008 at 5:37 AM, Sandro Tosi <morph@...> wrote:
> Hello guys!
> Following up the discussion Benjiamin and me had about a couple of
> bugs in Ubuntu[1] and Debian[2], and what Mike wrote on [1], we'd like
> to explore the possibility for you to develop a "backend=Auto" mode,
> that can discover automatically at runtime the backend to use from the
> ones available (in case of multiple backends, let's use a priority
> list [gtk, qt, tk, ...]).

This should be fairly easy to implement -- we already do something
like this at build time when we choose the default backend to put into
the template.  FYI, since you are a packager, I jwant to clarify what
happens at build time.  We have a file called setup.cfg.template which
is a template for people who want to override the default behavior.
You can copy this to setup.cfg and choose what default backend you
want, and the setup program will create an rc configured accordingly.
But if someone has not done this, the setup script will look (at build
time) for gtk, wx, and tk, and set the backend in order of increasing
preference: Agg, TkAgg, WXAgg, GTKAgg.  The file matplotlibrc.template
is then used to generate the default matplotlibrc, with this backend
selected.  This matplotlibrc is installed to matplotlib/mpl-data/ and
is used as the default config if the user does not override it.

As a debian/ubuntu packager, you will probably want to use setup.cfg
and set your backend manually.  You may want to use TkAgg since in
some ways this is the simplest backend to use in the most contexts,
primarily because it does not require special threading calls to work
interactively in the python shell -- see
http://matplotlib.sf.net/installing.html

But an "Auto" feature would be useful in other contexts too.  One area
is when matplotlib is embedded in a GUI IDE matlab-like application.
There are several of these that are being worked on in different user
interfaces, primarily using the new embeddable ipython, and the
concern there is that the user may be using one application which
embeds a python shell, and when users import pylab in that shell, the
ought not to have to think: "now I am using python in a wx app, so I
need to sert wxagg" but in other scenarios, "now I am using pylab in a
plain python shell so use tkagg"

The auto search algorithm should go something like the following:

* if tkinter, wx, gtk or qt has already been imported in sys.modules,
use that backend - Gael has already an implementation in the pyplot
module using the rc param 'backend_fallback'

 * if backend = 'auto': try in order of preference :tkagg (most
likely to work in most contexts), gtkagg, wxagg, qtagg.  This order
could easily be configurable

  * if none of the UIs are available in 'auto' mode, issue a warning
and set 'agg'

If I were packaging for ubuntu, I would select  tkagg as the default,
so you don't have to wade into the GNOME vs KDE arena and because it
works out of the box in the most contexts and is a pretty small
dependency.  You could modify the matplotlib runtime so that when the
.matplotlib directory is created (the first time mpl is run) it issues
a message like

  Creating config directory ~/.matplotlib.  The default user interface
toolkit for matplotlib is TkInter via the "TkAgg backend" (see
  http://matplotlib.sourceforge.net/faq/installing_faq.html#id1).  You
use other backends, you will need to install additional ubuntu
dependencies.
  For GTKAgg, install python-gtk, for WXAgg, install python-wxgtk, etc..."

> Personally, I think we can even attack the problem with a different
> solution: continue to ship all the mpl file in the "main" package
> (python-matplotlib in Debian & Ubuntu) and then create some "dummy"
> packages that simply depends on the python gui bindings (let's call
> them python-matplotlib-≤ui>), each of them providing a virtual
> package, let's call it python-matplotlib-backend. If python-matplotlib
> depends on python-matplotlib-gtk OR python-matplotlib-backend, any
> backend installed can satisfy that dependency (and the default being
> gtk).

That should work fine, but I advise installing all of mpl and use
these dummies only for dependencies.

> Both of them has cons: the first poses problem to us for the
> packaging, and both does not solve the problem of not choosing a
> default (or requiring to specify another package (the backend chosen)
> when installing python-matplotlib); moreover, what other packages
> depending on python-matplotlib should do after this change (they
> expect mpl to Just Work)?

Well, if the package that depends on mpl requires for example wx and
the wx backend, then it is enough for them to get a full mpl install
and handle the wx dependency in their package.  They would need to
make sure that the right mpl backend is selected when they import mpl,
but they can do that with the use directive.

> Another solution (that would save the most of the current work done),
> almost the same currently used today is: keep doing the same thing as
> of now, but do not install any python gui bindings, but popup a
> windows at python-matplotlib install time to ask the user what binding
> to use (then create the ad-hoc /etc/matplotlirc file with that
> "backend" set) and then ask to install the correct python binding for
> the backend chosen. A light version is: keep choosing gtk as default
> backend, and clearly document (even at install time) how to change
> backend.

This is in line with what I was suggesting, though I was suggesting it
at mpl first run time.  Either way could work.

I do see that this is a problem: a colleague of mine with a new ubuntu
8.10 box installed python-matplotlib as one of his first packages, and
it brought in 280 MB of packages, including several UI toolkits and a
full tex distribution.  I think the packagers are being over
inclusive.  For optional dependencies like usetex, which most people
do not use, and optional backends, it would be better to have a clear
set of instructions for users who want these optional features to
simply apt-get install the optional dependencies themselves.

JDH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Event handling example not working

Thanks - sorry for posting the mailing list address instead of the the
event handling page(!).  That'll teach me to email before
proof-reading...

2008/10/29 Ryan May <rmay31@...>:
> Neil Crighton wrote:
>> I noticed on the event handling doc page:
>>
>> matplotlib-devel@...
>>
>> that the draggable rectangle example doesn't work in version 0.98.3.
>> The rectangle class no longer seems to have the xy property.  If you
>> replace the current on_press() method in the example with the code
>> below it seem to work.
>>
>>     def on_press(self, event):
>>         'on button press we will see if the mouse is over us and store
>> some data'
>>         if event.inaxes != self.rect.axes: return
>>
>>         contains, attrd = self.rect.contains(event)
>>         if not contains: return
>>         xy = self.rect.get_x(),self.rect.get_y()
>>         print 'event contains', xy
>>         x0, y0 = xy
>>         self.press = x0, y0, event.xdata, event.ydata
>>
>
> Good catch.  I checked in a slightly different version of the fix.
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Event handling example not working

*re-reads email*

Apparently it won't teach me.

Sorry for the spam.

2008/11/3 Neil Crighton <neilcrighton@...>:
> Thanks - sorry for posting the mailing list address instead of the the
> event handling page(!).  That'll teach me to email before
> proof-reading...
>
> 2008/10/29 Ryan May <rmay31@...>:
>> Neil Crighton wrote:
>>> I noticed on the event handling doc page:
>>>
>>> matplotlib-devel@...
>>>
>>> that the draggable rectangle example doesn't work in version 0.98.3.
>>> The rectangle class no longer seems to have the xy property.  If you
>>> replace the current on_press() method in the example with the code
>>> below it seem to work.
>>>
>>>     def on_press(self, event):
>>>         'on button press we will see if the mouse is over us and store
>>> some data'
>>>         if event.inaxes != self.rect.axes: return
>>>
>>>         contains, attrd = self.rect.contains(event)
>>>         if not contains: return
>>>         xy = self.rect.get_x(),self.rect.get_y()
>>>         print 'event contains', xy
>>>         x0, y0 = xy
>>>         self.press = x0, y0, event.xdata, event.ydata
>>>
>>
>> Good catch.  I checked in a slightly different version of the fix.
>>
>> Ryan
>>
>> --
>> Ryan May
>> Graduate Research Assistant
>> School of Meteorology
>> University of Oklahoma
>>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Please test this patch on windows...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

Re: SVG clickable images

Hi,

I've attached a diff file which implements the basic functionality. It
currently doesn't handle collections or draw_image, but I wanted to
get something simple working first, before expanding the scope.  A
simple test program is as follows:

from pylab import *

f = figure()
a,b = bar([1,2], [2,5], url='http://www.bbc.co.uk/')

a.set_url('http://www.google.com')

f.canvas.print_figure(r'c:\test.svg')

I'd be interested in comments / feedback on the attached before I
start to branch out into more significant changes!

Thanks

Andrew

On Thu, Oct 30, 2008 at 8:02 PM, Michael Droettboom <mdroe@...> wrote:
> I realised in my earlier message, I didn't really address your initial
> request for feedback on your approach.
>
> I think the goal here should be to make the url support as pervasive as
> possible wrt both plot types and backends.
>
> Many of the high-level plotting functions (such as bar()) take a standard
> set of "Artist" keywords.  In the docs, you'll often see a table like the
> one at the bottom for bar():
>
>  http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.bar
>
> This support all happens automatically simply by adding a setter and getter
> to the "Artist" class.  So, in Artist, simply add set_url/get_url methods
> and a private attribute to store the url.  You shouldn't have to touch any
> of the high-level plotting functions to have this supported everywhere where
> it makes sense.
>
> Then, to use the url value, you'll want to store it in a GraphicsContext
> object to pass to the backend.  So you'll want to add an attribute and
> getter/setter in GraphicsContextBase as well.
>
> All of the places where the front-end creates a gc and passes it to the
> backend will need to be updated (such as Artist.draw, Text.draw, perhaps
> others, do a grep for the public methods in RendererBase).  Where it sets
> things like facecolor on the GraphicsContext, it should also set a url.
>
> Then, in backends where appropriate you would use the url value if present.
> You could start with SVG, and maybe someone can come along and add PDF
> support later.
>
> An additional complication for completeness is handling Collections.
>  Collections store a list of graphics context information (facecolor,
> edgecolor etc.) rather than a single one.  Therefore, you'll want to add
> set_urls/get_urls to Collection as well, and then deal with passing those
> values to the backend.  Collections don't use a GraphicsContext class, so
> you'll need to add a new arg to draw_path_collection in all backends.
>  (Refactoring this so we pass an object to the backends rather than a long
> list of arguments would be welcome to avoid needing to update multiple
> backends for these sorts of new features in the future).  You will also need
> to update RendererBase._iter_collection to support iterating over URLs in
> the same way as everything else there.
>
> draw_image also doesn't use a gc, so you'll need to add an argument there.
>
> Hope that gives you a road map...  Please let me know if I can help further.
>
> Mike
>
> Andrew Stock wrote:
>>
>> Hi,
>>
>> I have a requirement to make clickable bar charts using the SVG output
>> (rather than html maps).
>>
>> An initial look has suggested that the following changes would be
>> required:
>>
>> backend_bases.py: Add a url property to GraphicsContextBase
>> (defaulting to None, so it's all backwards compatible)
>> axes.py: Add a url option to the bar function and pass this on to the
>> constructor of the Rectangle object
>> patches.py: Pass the url option in the constructor for the Patch
>> object to the GraphicsContextBase object created in the draw function
>> backends/backend_svg.py: Add check to _draw_svg_element for url set in
>> gc. If it is, write out SVG code for xlink.
>>
>> I can make these changes and (if people think it would be useful)
>> contribute the changes back.  However, before I do this, I wanted to
>> check whether this is the right approach to take - I'm not experienced
>> with the internals of matplotlib and so if there's a better way of
>> doing it, I'd be grateful for the advice.
>>
>> Once I got the bar charts working, I would be interested in possibly
>> extending this to other chart types.
>>
>> Regards
>>
>> Andrew
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel@...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

Re: Please test this patch on windows...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

Re: SVG clickable images

This looks great to me.  I can confirm that this works on Linux as well.

I think from here it's just a matter of applying the same pattern of 
changes to collections and images.  Once that's done, I'm happy to apply 
the patch.  And if you plan to make a lot of changes in the future, it 
generally pretty easy to get commit access.  Just ask.

Mike

Andrew Stock wrote:
> Hi,
>
> I've attached a diff file which implements the basic functionality. It
> currently doesn't handle collections or draw_image, but I wanted to
> get something simple working first, before expanding the scope.  A
> simple test program is as follows:
>
> from pylab import *
>
> f = figure()
> a,b = bar([1,2], [2,5], url='http://www.bbc.co.uk/')
>
> a.set_url('http://www.google.com')
>
> f.canvas.print_figure(r'c:\test.svg')
>
> I'd be interested in comments / feedback on the attached before I
> start to branch out into more significant changes!
>
> Thanks
>
> Andrew
>
> On Thu, Oct 30, 2008 at 8:02 PM, Michael Droettboom <mdroe@...> wrote:
>   
>> I realised in my earlier message, I didn't really address your initial
>> request for feedback on your approach.
>>
>> I think the goal here should be to make the url support as pervasive as
>> possible wrt both plot types and backends.
>>
>> Many of the high-level plotting functions (such as bar()) take a standard
>> set of "Artist" keywords.  In the docs, you'll often see a table like the
>> one at the bottom for bar():
>>
>>  http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.bar
>>
>> This support all happens automatically simply by adding a setter and getter
>> to the "Artist" class.  So, in Artist, simply add set_url/get_url methods
>> and a private attribute to store the url.  You shouldn't have to touch any
>> of the high-level plotting functions to have this supported everywhere where
>> it makes sense.
>>
>> Then, to use the url value, you'll want to store it in a GraphicsContext
>> object to pass to the backend.  So you'll want to add an attribute and
>> getter/setter in GraphicsContextBase as well.
>>
>> All of the places where the front-end creates a gc and passes it to the
>> backend will need to be updated (such as Artist.draw, Text.draw, perhaps
>> others, do a grep for the public methods in RendererBase).  Where it sets
>> things like facecolor on the GraphicsContext, it should also set a url.
>>
>> Then, in backends where appropriate you would use the url value if present.
>> You could start with SVG, and maybe someone can come along and add PDF
>> support later.
>>
>> An additional complication for completeness is handling Collections.
>>  Collections store a list of graphics context information (facecolor,
>> edgecolor etc.) rather than a single one.  Therefore, you'll want to add
>> set_urls/get_urls to Collection as well, and then deal with passing those
>> values to the backend.  Collections don't use a GraphicsContext class, so
>> you'll need to add a new arg to draw_path_collection in all backends.
>>  (Refactoring this so we pass an object to the backends rather than a long
>> list of arguments would be welcome to avoid needing to update multiple
>> backends for these sorts of new features in the future).  You will also need
>> to update RendererBase._iter_collection to support iterating over URLs in
>> the same way as everything else there.
>>
>> draw_image also doesn't use a gc, so you'll need to add an argument there.
>>
>> Hope that gives you a road map...  Please let me know if I can help further.
>>
>> Mike
>>
>> Andrew Stock wrote:
>>     
>>> Hi,
>>>
>>> I have a requirement to make clickable bar charts using the SVG output
>>> (rather than html maps).
>>>
>>> An initial look has suggested that the following changes would be
>>> required:
>>>
>>> backend_bases.py: Add a url property to GraphicsContextBase
>>> (defaulting to None, so it's all backwards compatible)
>>> axes.py: Add a url option to the bar function and pass this on to the
>>> constructor of the Rectangle object
>>> patches.py: Pass the url option in the constructor for the Patch
>>> object to the GraphicsContextBase object created in the draw function
>>> backends/backend_svg.py: Add check to _draw_svg_element for url set in
>>> gc. If it is, write out SVG code for xlink.
>>>
>>> I can make these changes and (if people think it would be useful)
>>> contribute the changes back.  However, before I do this, I wanted to
>>> check whether this is the right approach to take - I'm not experienced
>>> with the internals of matplotlib and so if there's a better way of
>>> doing it, I'd be grateful for the advice.
>>>
>>> Once I got the bar charts working, I would be interested in possibly
>>> extending this to other chart types.
>>>
>>> Regards
>>>
>>> Andrew
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>       
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>>     

--

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: SF.net SVN: matplotlib:[6363] trunk/matplotlib/examples/pylab_examples/ text_rotation_relative_to_line.py

Thanks, David.  That's a much-needed feature.

However, wouldn't it be simpler, API-wise, to add a new kwarg 
"rotation_data" (or some better name) which would be an angle in data 
space?  (Or alternatively a boolean flag "rotation_in_data_coords").  
The other advantage of that approach is that since the Text object knows 
what the "purpose" of the angle is, it could update the angle when the 
limits or figure size are changed.

It looks like the heavy lifting of the calculation is already there...

Cheers,
Mike

dmkaplan@... wrote:
> Revision: 6363
>           http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6363&view=rev
> Author:   dmkaplan
> Date:     2008-11-05 14:43:29 +0000 (Wed, 05 Nov 2008)
>
> Log Message:
> -----------
> Adding a small script that demonstrates the utility of transform_angles method added in last
> commit (from dmkaplan).
>
> Added Paths:
> -----------
>     trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py
>
> Added: trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py
> ===================================================================
> --- trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py	                        (rev 0)
> +++ trunk/matplotlib/examples/pylab_examples/text_rotation_relative_to_line.py	2008-11-05
14:43:29 UTC (rev 6363)
> @@ -0,0 +1,36 @@
> +#!/usr/bin/env python
> +"""
> +Text objects in matplotlib are normally rotated with respect to the
> +screen coordinate system (i.e., 45 degrees rotation plots text along a
> +line that is inbetween horizontal and vertical no matter how the axes
> +are changed).  However, at times one wants to rotate text with respect
> +to something on the plot.  In this case, the correct angle won't be
> +the angle of that object in the plot coordinate system, but the angle
> +that that object APPEARS in the screen coordinate system.  This angle
> +is found by transforming the angle from the plot to the screen
> +coordinate system, as shown in the example below.
> +"""
> +from pylab import *
> +
> +# Plot diagonal line (45 degrees)
> +h = plot( r_[:10], r_[:10] )
> +
> +# set limits so that it no longer looks on screen to be 45 degrees
> +xlim([-10,20])
> +
> +# Locations to plot text
> +l1 = array((1,1))
> +l2 = array((5,5))
> +
> +# Rotate angle
> +angle = 45
> +trans_angle = gca().transData.transform_angles(array((45,)),
> +                                               l2.reshape((1,2)))[0]
> +
> +# Plot text
> +th1 = text(l1[0],l1[1],'text not rotated correctly',fontsize=16,
> +           rotation=angle)
> +th2 = text(l2[0],l2[1],'text not rotated correctly',fontsize=16,
> +           rotation=trans_angle)
> +
> +show()
>
>
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open
Source development site.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-checkins mailing list
> Matplotlib-checkins@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins
>   

--

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/