API change in transforms branch

Mike: I see that ax.apply_aspect now has a 'position' argument. To maintain backward compatibility, may I suggest that you make it a kwarg, with default value None, and then add

if position is None:
    position = self._originalPosition

at the top of apply_aspect?

-Jeff

···

--
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

It may be now be tricky to call apply_aspect correctly. With the recent auto-layout changes, it's required to be called after the text layout has been done, but before it has been drawn. What is your use case for calling it outside of that? Do you need to set and then use the aspect-adjusted axes position? Since apply_aspect is always called from within draw() anyway, for most uses, calling outside of that would be redundant, and I was considering making it a private method. If you don't call it from your code, is anything different?

Cheers,
Mike

Jeff Whitaker wrote:

···

Mike: I see that ax.apply_aspect now has a 'position' argument. To maintain backward compatibility, may I suggest that you make it a kwarg, with default value None, and then add

if position is None:
   position = self._originalPosition

at the top of apply_aspect?

-Jeff

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

Michael Droettboom wrote:

It may be now be tricky to call apply_aspect correctly. With the recent auto-layout changes, it's required to be called after the text layout has been done, but before it has been drawn. What is your use case for calling it outside of that? Do you need to set and then use the aspect-adjusted axes position? Since apply_aspect is always called from within draw() anyway, for most uses, calling outside of that would be redundant, and I was considering making it a private method. If you don't call it from your code, is anything different?

Cheers,
Mike

Mike: Perhaps I am just misusing it - I thought you had to call it for the set_aspect to take effect. I didn't realize it was called from draw(). I'll try removing it and re-run all the basemap examples to see if there are any side effects.

-Jeff

···

Jeff Whitaker wrote:

Mike: I see that ax.apply_aspect now has a 'position' argument. To maintain backward compatibility, may I suggest that you make it a kwarg, with default value None, and then add

if position is None:
   position = self._originalPosition

at the top of apply_aspect?

-Jeff

--
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Michael Droettboom wrote:

It may be now be tricky to call apply_aspect correctly. With the recent auto-layout changes, it's required to be called after the text layout has been done, but before it has been drawn. What is your use case for calling it outside of that? Do you need to set and then use the aspect-adjusted axes position? Since apply_aspect is always called from within draw() anyway, for most uses, calling outside of that would be redundant, and I was considering making it a private method. If you don't call it from your code, is anything different?

Cheers,
Mi

Mike: The only side effect of not calling apply_aspect that I can see involves the use of ax.get_position(). The axes position that you get is not what will ultimately be drawn on the figure unless you call apply_aspect before get_position. This comes into play when setting the position of colorbar axes, since you want them to line up with the axes of the image.

-Jeff

···

Jeff Whitaker wrote:

Mike: I see that ax.apply_aspect now has a 'position' argument. To maintain backward compatibility, may I suggest that you make it a kwarg, with default value None, and then add

if position is None:
   position = self._originalPosition

at the top of apply_aspect?

-Jeff

--
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Jeff Whitaker wrote:

Michael Droettboom wrote:

It may be now be tricky to call apply_aspect correctly. With the recent auto-layout changes, it's required to be called after the text layout has been done, but before it has been drawn. What is your use case for calling it outside of that? Do you need to set and then use the aspect-adjusted axes position? Since apply_aspect is always called from within draw() anyway, for most uses, calling outside of that would be redundant, and I was considering making it a private method. If you don't call it from your code, is anything different?

Cheers,
Mi

Mike: The only side effect of not calling apply_aspect that I can see involves the use of ax.get_position(). The axes position that you get is not what will ultimately be drawn on the figure unless you call apply_aspect before get_position. This comes into play when setting the position of colorbar axes, since you want them to line up with the axes of the image.

That makes sense. I'll do what you suggest for now -- but unfortunately, apply_aspect is no longer "good enough" to determine the ultimate position of the axes, since they can also be adjusted based on the surrounding text now.

Alas, this auto-layout thing gets more complicated. I'll have to figure out something more robust (possibly combining the text-overlapping-prevention and the aspect ratio into a single call somehow).

Cheers,
Mike

···

Jeff Whitaker wrote:

Mike: I see that ax.apply_aspect now has a 'position' argument. To maintain backward compatibility, may I suggest that you make it a kwarg, with default value None, and then add

if position is None:
   position = self._originalPosition

at the top of apply_aspect?

-Jeff

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