API change in transforms branch

re autolayout; how does this affect gcf().subplots_adjust(hspace=1.),
which is how I would make room (where hspace can be adjusted)?

That should continue to work. It will create more space than you probably want, though, since it will add the manually-added space and the automatically-added space together.

It's an open question whether autolayout may start ignoring the adjust requests or not as a backward compatibility measure. I still consider this stuff a long way off until it's usable in general.

Cheers,
Mike

Tom Holroyd wrote:

···

re autolayout; how does this affect gcf().subplots_adjust(hspace=1.),
which is how I would make room (where hspace can be adjusted)?

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

My feeling is that it is not a good idea to try and support the manual
layout and the autolayout with the same set of parameters, but how to
get this segregation right may be difficult in practice. Eg, it is
probably better to have something like a vbox and hbox pad that the
user can configure for the autolayout if they want to increase the
whitespace between the axes using autolayout, rather than trying to
support the subplots adjust parameters. Depending on the
figure.autolayout setting, one might launch a different GUI widget
panel (eg the subplots_adjust widgets if autolayout is False, and a
different widget with different params if it is True).

JDH

···

On Dec 6, 2007 8:03 AM, Michael Droettboom <mdroe@...31...> wrote:

It's an open question whether autolayout may start ignoring the adjust
requests or not as a backward compatibility measure. I still consider
this stuff a long way off until it's usable in general.

And, another goal for layout (if it has not already been achieved) might be to make it easy to end up with a tight bounding box. That is, to end up with the plot nicely filling the allotted space, to the extent that it can given specified aspect ratio. One of the repeated complaints about mpl is that one can easily end up with quite a bit of unneeded whitespace on the periphery.

Another goal might be to make it easy to specify axes dimensions in physical units, or to specify data-to-physical-units conversion factors. For example, sometimes one wants to make many plots with 100 m vertical data units to 1 inch on the page, and 1 degree latitude to 1/2 inch on the page.

(Quick thoughts, file or discard as needed--sorry I can't do more at the moment.)

Eric

John Hunter wrote:

···

On Dec 6, 2007 8:03 AM, Michael Droettboom <mdroe@...31...> wrote:

It's an open question whether autolayout may start ignoring the adjust
requests or not as a backward compatibility measure. I still consider
this stuff a long way off until it's usable in general.

My feeling is that it is not a good idea to try and support the manual
layout and the autolayout with the same set of parameters, but how to
get this segregation right may be difficult in practice. Eg, it is
probably better to have something like a vbox and hbox pad that the
user can configure for the autolayout if they want to increase the
whitespace between the axes using autolayout, rather than trying to
support the subplots adjust parameters. Depending on the
figure.autolayout setting, one might launch a different GUI widget
panel (eg the subplots_adjust widgets if autolayout is False, and a
different widget with different params if it is True).

JDH

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options