matplotlib-devel Mailing List for matplotlib

On Tuesday 30 October 2007 11:07:32 am you wrote:
> On 10/29/07, Darren Dale <dar...@co...> wrote:
> > Maybe we can consider switching to the traited config package after the
> > potential merge. I have been running with it for quite a long time, and
>
> I think it would be a good time to do the switch. Michael's changes
> do not change much of the API, but there are a number of places where
> there will be changes, and so it is a good idea to get as many of
> these things in at once. I think a good way to proceed will be to
> treat this as a pre-pre 1.0 release (0.98?), with widely advertised
> changes, so people will expect some pain in the upgrade. The only
> other major thing I want to see overhauled before 1.0 is the axis
> treatment, so people can add an arbitrary number of x and y axis
> instances with different scaling and placement.
>
> I am also mostly in agreement with Eric that I am hesitant to rely on
> traits as an external dependency. When I first started testing traits
> this summer and did the install on my powerbook, the install was
> anything but painless. The team on the enthought-dev mailing lists
> was awesome in their support, but it took a lot of support for me to
> get everything working right, and I was at least 10 times more
> motivated, and probably more competent, than the typical user. When
> there is a single tarball or command that works on almost all
> platforms, and continues to do so for six months or so, I am amenable
> to making it an external dependency, which is the approach enthought
> prefers and which has its own advantages . Darren, how much work
> would it take to get traits 3.0 into our install pipline?
I think that part should be pretty easy. The hard part is writing the default 
config file during development and then updating it at build time depending 
on the available backends, etc. Solving that problem would be easy with an 
external traits, but with an internal package, I don't think we will have 
access to the machinery of tconfig until "setup.py install" has been run, is 
that correct? I'll come up with some kind of workaround.
> Proposed timeline:
>
> * get out a release of the current trunk, and make a branch for bug
> fix releases
>
> * merge Michael's branch into the trunk with emails to the lists and
> posts to the site that svn is bleeding edge, and this time we mean it,
> with instructions on how to use the oldline branch for people who need
> up to the minute bug fixes in the old branch
I think we should consider an mpl1 branch and a temporary dev mailing list for 
that branch, like they did with py3k. It would be less disruptive to the many 
users who already run svn-mpl. Then when people complain that mpl-0.98 is 
broken, we can tell them they asked for it :) 
> * bring enthought traits 3.0 into our build pipeline
>
> * turn on traited config, and deprecate the old config.
>
> * add traited properties for the artists.
At this point, we should start using the traited config object directly, and 
add deprecation warnings in the rcParams wrapper.
> * release 0.98 sometime early next year.
>
> We probably want to consult with the ipython folks to see what their
> plans are vis-a-vis traits and config to see if there is any
> duplication of effort we can avoid.
Darren

On 10/29/07, Darren Dale <dar...@co...> wrote:
> Maybe we can consider switching to the traited config package after the
> potential merge. I have been running with it for quite a long time, and
I think it would be a good time to do the switch. Michael's changes
do not change much of the API, but there are a number of places where
there will be changes, and so it is a good idea to get as many of
these things in at once. I think a good way to proceed will be to
treat this as a pre-pre 1.0 release (0.98?), with widely advertised
changes, so people will expect some pain in the upgrade. The only
other major thing I want to see overhauled before 1.0 is the axis
treatment, so people can add an arbitrary number of x and y axis
instances with different scaling and placement.
I am also mostly in agreement with Eric that I am hesitant to rely on
traits as an external dependency. When I first started testing traits
this summer and did the install on my powerbook, the install was
anything but painless. The team on the enthought-dev mailing lists
was awesome in their support, but it took a lot of support for me to
get everything working right, and I was at least 10 times more
motivated, and probably more competent, than the typical user. When
there is a single tarball or command that works on almost all
platforms, and continues to do so for six months or so, I am amenable
to making it an external dependency, which is the approach enthought
prefers and which has its own advantages . Darren, how much work
would it take to get traits 3.0 into our install pipline?
Proposed timeline:
 * get out a release of the current trunk, and make a branch for bug
fix releases
 * merge Michael's branch into the trunk with emails to the lists and
posts to the site that svn is bleeding edge, and this time we mean it,
with instructions on how to use the oldline branch for people who need
up to the minute bug fixes in the old branch
 * bring enthought traits 3.0 into our build pipeline
 * turn on traited config, and deprecate the old config.
 * add traited properties for the artists.
 * release 0.98 sometime early next year.
We probably want to consult with the ipython folks to see what their
plans are vis-a-vis traits and config to see if there is any
duplication of effort we can avoid.

Just to clarify: the OFFICIAL definition of an inch is 2.54 cm.
So rounding errors shouldn't be much of a problem.
> Date: 2007年10月29日 09:37:06 -0400
> From: Michael Droettboom <md...@st...>
>
> I agree that we have to remain in inches internally. Non-metric units
> are pretty ingrained in the printing world (not just in matplotlib) --
> Postscript, for example, always does page sizes in inches, even if
> you're using a "metric" page size like A4. The current definition of a
> point as 1/72 of a modern inch is also fairly standard worldwide. Even
> printers in France, for example, are spec'd in points par pouce (ppp),
> which is exactly equivalent to dots per inch (dpi).
>
> However, that's just an implementation detail we have to stick with.
> Matplotlib has Figure.get/set_size_inches now. What's to stop us from
> adding get/set_size_cm, and doing the conversion right there? There
> might be some rounding error, but I don't think it matters in this
> particular case. We would probably also want to add a "figsize_cm"
> kwarg to the Figure constructor (which would be mutually exclusive to
> "figsize"). What do you think?
>
> Cheers,
> Mike
>
>