matplotlib-devel Mailing List for matplotlib

Darren Dale <dd...@co...> writes:
>> > OK, I refactored TextWithDash, and my changes passed backend_driver.py.
>> > setp(axes().get_yticklabels()) gives a comprehensive list as of svn 2206.
>
> I fixed the bug John pointed out, and unmasked the refactored version of 
> TextWithDash in svn 2226. 
Yes, 'size' is listed in the output now. However, now it seems that
there are too many things listed: 
 label: any string
 text: string
The commands setp(gca().get_yticklabels()[0], 'label', 'foo') and
setp(..., 'text', 'foo') do nothing. Of course, the right way to
modify the tick labels is to call gca().set_yticklabels(['foo',...]) 
(or setp(gca(), 'yticklabels', ['foo',...])) which does quite some
magic to change the label text (e.g., the Axis object's major
formatter is changed into FixedFormatter(ticklabels)). Having 'label'
and 'text' listed in the setp output could mislead people.
However, if you draw a TextWithDash yourself, you _can_ change the
text with setp, and indeed the docstring claims that TextWithDash is
"intended to be a drop-in replacement for Text". E.g., the following
works: t=text(1,1,'foo',withdash=True); setp(t,'text', 'bar'); 
So it wouldn't be right to simply remove set_text from TextWithDash,
which would otherwise have been my suggestion.
-- 
Jouni

On Wednesday 22 March 2006 14:24, Darren Dale wrote:
> On Wednesday 22 March 2006 09:49, Darren Dale wrote:
> > On Tuesday 21 March 2006 18:53, John Hunter wrote:
> > > >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> > >
> > > Darren> The reason is that TextWithDash has a Text object
> > > Darren> attribute and delegates most of its methods to that object
> > > Darren> via __getattr__ and __setattr__. Can anyone tell me why
> > > Darren> this approach was favored over deriving TextWithDash from
> > > Darren> Text?
> > >
> > > I think __getattr__ and __setattr__ are mostly evil since they lead to
> > > hard to debug code and break things like tab completion in ipython and
> > > object inspection. I'm +1 for refactoring TextWiithDashes to use
> > > inheritance or otherwise expose the attributes directly.
> >
> > OK, I refactored TextWithDash, and my changes passed backend_driver.py.
> > setp(axes().get_yticklabels()) gives a comprehensive list as of svn 2206.
> > The old TextWithDash is still there, but masked, just in case.
>
> Strike that, John found a bug that was exposed by dashtick. I reverted back
> to the old behavior.
I fixed the bug John pointed out, and unmasked the refactored version of 
TextWithDash in svn 2226. 
Darren

On 3/22/06, Eric Firing <ef...@ha...> wrote:
> unintuitive. Maybe we could find better names than 'equal' and
> 'scaled', for example. Even with the docstrings, I have a hard time
> keeping track of which is supposed to do what.
Hi,
I think it would be nice if pylab "semantics" were kept close to matlab.
Maybe for instance axis('scaled') could be renamed to axis('image'), and
use similar wording as mathworks documentation in the docstrings?
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/axis.html
Helge

On Wednesday 22 March 2006 2:38 pm, Darren Dale wrote:
> On Tuesday 21 March 2006 19:10, John Hunter wrote:
> > >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> >
> > Darren> The problem is in draw_line_collection, and it looks
> > Darren> complicated.
> >
> > OK, I just committed a "fix" for this problem. There is no elegant
> > way to do it in backend bases because of the way collections use
> > offsets and offset transforms. So I just hacked it up to do the
> > transformations as before and pass an identity transform off to the
> > backend in using the newstyle API. Another argument for implementing
> > the methods in the backends....for a rainy day.
>
> My implementation of draw_lines is not compatible with
> draw_line_collection. I'm masking draw_markers in CVS until I get the
> problem sorted out.
Game on!
The new API is functional again in the postscript backend. All the bugs I am 
aware of have been cleared. I'm holding off on a note to the CHANGELOG until 
we go a few days without bug reports.
Darren