matplotlib-devel Mailing List for matplotlib

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> I am getting more comfortable with 'scaled' now. The problem
    Eric> is that neither 'equal' nor 'scaled' is as obvious as one

I think a mini-tutorial on aspect handling for axes and images,
especially with screenshots that show the different effects, and a
discussion of all the wild-and-wooly options would be a great addition
to the wiki.

JDH

Mark,

Mark Bakker wrote:
> Sorry that I have not been involved much in the reworking of the
> aspect ratio handling, but I have been travelling (I know, what
> an excuse is that).
> 
> Regarding the options used, the 'equal' option mimics matlab, both
> in functionality and in name. Besides, I think it is not a bad descriptor,
> so my vote is to keep it.
> 
> The 'scaled' term I made up. It might be a bad word, but the functionality
> is much more useful IMHO in that it keeps the limits on the axes
> and it changes the size of the plotting area such that the axes are scaled.
> The 'equal' option is surely a pain in the ass to use I think, as any time
> you add something to the damn figure, it will reset the axes limits. But,
> if former matlab users want it, I don't mind keeping it.

I am getting more comfortable with 'scaled' now. The problem is that 
neither 'equal' nor 'scaled' is as obvious as one would like.  Both set 
the data aspect ratio to 1, the first by changing the plot box 
dimensions and the second by changing the data view limits, but this is 
not obvious from the usage axis('equal') and axis('scaled').  It may be 
the best we can do, so I don't mind leaving it.  Both 'equal' and 
'scaled' functionality have important uses.

The Axes.set_aspect method is more verbose and expressive:

     def set_aspect(self, aspect, adjustable=None, anchor=None):
         """
         aspect:
            'auto'   -  automatic; fill position rectangle with data
            'normal' -  same as 'auto'; deprecated
            'equal'  -  same scaling from data to plot units for x and y
             num     -  a circle will be stretched such that the height
                        is num times the width. aspect=1 is the same as
                        aspect='equal'.

         adjustable:
             'box'      - change physical size of axes
             'datalim'  - change xlim or ylim

         anchor:
             'C'     - centered
             'SW'    - lower left corner
             'S'     - middle of bottom edge
             'SE'    - lower right corner
                  etc.

         ACCEPTS: ['auto' | 'equal' | aspect_ratio]
         """

The kwargs also have their own set methods; the kwargs are included in 
set_aspect so that it can be used to set everything in one line.

I see now that I need to add to the docstring the clarification that the 
anchor kwarg is active only for adjustable=box.

Jeff,

This is where I put the plot-box location option.  I used the Tk-style 
"anchoring" terminology because it seems to me to be very compact, 
expressive, and easy to remember.  Unfortunately, it differs from what 
is used in the legend command.  If there is any sentiment that it would 
be desirable, I could make legend understand it as well, for the sake of 
consistency.

I have not tried to load the anchor options into the pylab axis command; 
I think this would be making it too complicated, for no real benefit.  I 
consider pylab to be mainly for interactive use, for which the 
simplicity/power tradeoff should be biased towards simplicity.

All,

I factored the plot box resizing and repositioning code out into a PBox 
class ("Position Box", subclassed from list), presently in its own 
pbox.py file, because I think it will be more generally useful; the 
colorbar command is one such intended use.  It may be helpful to make 
Axes._position a PBox instance instead of an ordinary list.

I think that aspect-ratio handling is now reasonably solid and complete; 
I have tested it with pan and zoom, with and without ganged axes.  I had 
to put in a couple of hacks in backend_bases to prevent exceptions. 
(More careful analysis and fixing of the underlying causes would be 
good.) Testing by other people would be very useful; you are likely 
(maybe I should say 'certain') to try combinations of commands and 
events I have not tested, which will turn up additional problems.

In case I failed to mention it in an earlier post: PolarAxes now uses 
aspect-ratio handling to keep circles circular when windows are resized.

> 
> I'll try to find time to test Eric's new implementation soon. Thanks for
> all the hard work,

Thank you, Mark, for the original work that made the changes possible.

Eric

> 
> Mark
> 
> Helge Avlesen wrote:
>  > On 3/22/06, Eric Firing < ef...@ha... 
> <mailto: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
> 
> Helge,
> 
> I understand the sentiment, but I don't always agree with it; while I
> don't want to do things differently from Matlab just for the sake of
> being different (except insofar is it may be necessary to avoid
> violating copyright), neither do I want to slavishly follow Matlab.
> Pylab/matplotlib can and should be better than Matlab.  (And is in many
> respects.)
> 
> In the case of Matlab's axis command, the Matlab documentation makes my
> head spin, and the whole command strikes me as too complicated for
> anyone's good.  I don't think every possible capability should go into
> the pylab interface; past a certain point, it is better to simply call
> axis methods, etc.
> 
> For now, I have added an axis('image') mode, which is not quite the same
> as 'scaled', and I have tried to improve the descriptions of the
> options.  Please try out the various axis modes, and see if you think
> both the behavior and the descriptions make sense.
> 
> Eric

Sorry that I have not been involved much in the reworking of the
aspect ratio handling, but I have been travelling (I know, what
an excuse is that).

Regarding the options used, the 'equal' option mimics matlab, both
in functionality and in name. Besides, I think it is not a bad descriptor,
so my vote is to keep it.

The 'scaled' term I made up. It might be a bad word, but the functionality
is much more useful IMHO in that it keeps the limits on the axes
and it changes the size of the plotting area such that the axes are scaled.
The 'equal' option is surely a pain in the ass to use I think, as any time
you add something to the damn figure, it will reset the axes limits. But,
if former matlab users want it, I don't mind keeping it.

I'll try to find time to test Eric's new implementation soon. Thanks for
all the hard work,

Mark

Helge Avlesen wrote:
> 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

Helge,

I understand the sentiment, but I don't always agree with it; while I
don't want to do things differently from Matlab just for the sake of
being different (except insofar is it may be necessary to avoid
violating copyright), neither do I want to slavishly follow Matlab.
Pylab/matplotlib can and should be better than Matlab.  (And is in many
respects.)

In the case of Matlab's axis command, the Matlab documentation makes my
head spin, and the whole command strikes me as too complicated for
anyone's good.  I don't think every possible capability should go into
the pylab interface; past a certain point, it is better to simply call
axis methods, etc.

For now, I have added an axis('image') mode, which is not quite the same
as 'scaled', and I have tried to improve the descriptions of the
options.  Please try out the various axis modes, and see if you think
both the behavior and the descriptions make sense.

Eric

On Thu, 30 Mar 2006, John Hunter wrote:

>>>>>> "Pearu" == Pearu Peterson <pe...@sc...> writes:
>
>    Pearu> Without the patch I get:
>
> Are you using matplotlib subversion?

Hmm, I was using cvs.., I didn't notice the switch to svn.

> What does
>
>  >>> import matplotlib
>  >>> matplotlib.__version__
>
> report?

>>> import matplotlib
>>> matplotlib.__version__
'0.87.1cvs'


> My guess is that this was fixed by Travis' commit that imported the
> old linalg namespace
>
> elif which[0] == "numpy":
>    from numpy.linalg import *
>    inverse = inv
>    eigenvectors = eig
>    try:
>        from numpy.linalg.old import *
>    except:
>        pass
>
> I am not getting your import error w/ current numpy snv (rev 2312)

Ok, I'll switch to svn.


Thanks,
Pearu

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> I shoudl have tried this in the first place.  The
    Charlie> widgets/radio_buttons.py example doesn't work at all for
    Charlie> me.  In fact quite a few are broken.

I noticed today that the subplots_adjust toolbar widget is broken
too... So this is a fairly high priority bug.

JDH

>>>>> "Pearu" == Pearu Peterson <pe...@sc...> writes:

    Pearu> Without the patch I get:

Are you using matplotlib subversion?  What does

  >>> import matplotlib
  >>> matplotlib.__version__

report?

My guess is that this was fixed by Travis' commit that imported the
old linalg namespace

elif which[0] == "numpy":
    from numpy.linalg import *
    inverse = inv
    eigenvectors = eig
    try:
        from numpy.linalg.old import *
    except:
        pass

I am not getting your import error w/ current numpy snv (rev 2312)

JDH

On Thu, 30 Mar 2006, John Hunter wrote:

>>>>>> "Pearu" == Pearu Peterson <pe...@sc...> writes:
>    Pearu> This fixes import errors when using only numpy.
>
> which import errors?  I updated from numpy svn today and did a clean
> build and test against matplotlib's poor man's regression suite using
>
>>>> import numpy
>>>> numpy.__version__
> '0.9.7.2310'
>
> and did not encounter any errors....  Or is my numpy version already
> woefully out of date :-) ?

Without the patch I get:

>>> import pylab
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/local/lib/python2.3/site-packages/pylab.py", line 1, in ?
     from matplotlib.pylab import *
   File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 
200, in ?
     from axes import Axes, PolarAxes
   File "/usr/local/lib/python2.3/site-packages/matplotlib/axes.py", line 
14, in ?
     from artist import Artist, setp
   File "/usr/local/lib/python2.3/site-packages/matplotlib/artist.py", line 
4, in ?
     from transforms import identity_transform
   File "/usr/local/lib/python2.3/site-packages/matplotlib/transforms.py", 
line 193, in ?
     from matplotlib.numerix.linear_algebra import inverse
ImportError: cannot import name inverse
>>>

Pearu

>>>>> "Pearu" == Pearu Peterson <pe...@sc...> writes:
    Pearu> This fixes import errors when using only numpy.

which import errors?  I updated from numpy svn today and did a clean
build and test against matplotlib's poor man's regression suite using

>>> import numpy
>>> numpy.__version__
'0.9.7.2310'

and did not encounter any errors....  Or is my numpy version already
woefully out of date :-) ?

JDH

Index: lib/matplotlib/numerix/linear_algebra/__init__.py
===================================================================
RCS file: 
/cvsroot/matplotlib/matplotlib/lib/matplotlib/numerix/linear_algebra/__init__.py,v
retrieving revision 1.5
diff -r1.5 __init__.py
8a9,10
>     inverse = inv
>     eigenvectors = eig

This fixes import errors when using only numpy.

Regards,
Pearu

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> I think what you are proposing is a bit different from what
    Eric> John suggested in his subsequent message, but a common
    Eric> element is the separation of Axes nuts and bolts from
    Eric> fancier plotting.  I will do that relatively simple job
    Eric> first; I think it will facilitate any subsequent more
    Eric> extensive refactoring.

This is an odd time to bring this up, when we are trying to prune the
Axes class, but I am trying to remove any pure pylab functionality.
To whit: 'setp' and 'getp' have been recently moved to
matplotlib.artist, 'load' and 'save' to matplotlib.mlab, and so on.
Basically, I want to have some ammunition when people complain that
the OO interface is harder to use than the pylab interface :-)

Which brings me to the 'axis' command.  This is one of the few
remaining truly useful pieces of pylab functionality.  Should this not
be a method of Axes (in the current, non-refactored understanding of
Axes)?

In any case, Eric, since you are intimately familiar with both axis
and the phase-I refactoring of Axes, I think this would be a good time
to make axis functionality available to non-pylab users, wherever it
fits best.

JDH

Helge Avlesen wrote:
> 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

Helge,

I understand the sentiment, but I don't always agree with it; while I 
don't want to do things differently from Matlab just for the sake of 
being different (except insofar is it may be necessary to avoid 
violating copyright), neither do I want to slavishly follow Matlab. 
Pylab/matplotlib can and should be better than Matlab.  (And is in many 
respects.)

In the case of Matlab's axis command, the Matlab documentation makes my 
head spin, and the whole command strikes me as too complicated for 
anyone's good.  I don't think every possible capability should go into 
the pylab interface; past a certain point, it is better to simply call 
axis methods, etc.

For now, I have added an axis('image') mode, which is not quite the same 
as 'scaled', and I have tried to improve the descriptions of the 
options.  Please try out the various axis modes, and see if you think 
both the behavior and the descriptions make sense.

Eric

Jouni K Seppanen wrote:
> Eric Firing <ef...@ha...> writes:
> 
> 
>>The main organizational change would separate the functionality that
>>is directly involved in manipulating the axes from the more specific
>>plotting methods.  This could be done, for example, by putting the
>>former in an AxesBase class, and then letting Axes inherit that.
> 
> 
> IMHO, it would make sense in the long term to make Axes a low-level
> class with a well-defined interface, and implement high-level plotting
> methods such as bar, boxplot, cohere, hist, specgram and what have you
> using that interface outside of Axes. Currently at least some of these
> methods "peek under the hood" by doing things like
> 
>     if not self._hold: self.cla()
> 
> This looks like it will be a pain to maintain if the implementation
> details ever change. self._hold could probably be easily replaced by
> self.ishold(), but moving the methods to another class would help
> ensure that they stay kosher.
> 

Jouni,

I think what you are proposing is a bit different from what John 
suggested in his subsequent message, but a common element is the 
separation of Axes nuts and bolts from fancier plotting.  I will do that 
relatively simple job first; I think it will facilitate any subsequent 
more extensive refactoring.

Eric

>>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes:

    Malte> You are looking for matplotlib.axes.Subplot.set_position

That will work, but what you are really looking for is to not use
subplot at all, but rather axes; a Subplot is just an Axes that happens
to lie on a regular grid

  axes_top    = fig.add_axes([0.1, 0.3, 0.8, 0.6])
  axes_bottom = fig.add_axes([0.1, 0.1, 0.8, 0.15])

If you want the two axes to touch and share and xaxis, see
examples/ganged_plots.py.  There are nice tricks you can do to share
an xaxis so for example when you pan/zoom in one the xaxis in both
plots move together; see examples/shared_axis_demo.py

JDH

You are looking for

matplotlib.axes.Subplot.set_position

set_position(self, pos) method of matplotlib.axes.Subplot instance
    Set the axes position with pos = [left, bottom, width, height]
    in relative 0,1 coords

    ACCEPTS: len(4) sequence of floats

axes_top.set_position([left, bottom, width, height])

etc.

On Friday 31 March 2006 08:38, Andrew B. Young wrote:
> Hello:
>
> How does one go about controlling the size of a subplot?
> I've got--
>
>     figure = matplotlib.pylab.Figure()
>     canvas = FigureCanvas( figure )
>     axes_top = figure.add_subplot(211)
>     axes_bottom = figure.add_subplot(212)
>
> and I want the _top to occupy 4/5 of the png
> and the _bottom to occupy the remaining 1/5.
>
> Thanks!
> Andrew

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
    Darren> I dont think that can work, since
    Darren> set_xticklabels(['foo',...]) makes its own call to
    Darren> set_text('foo').

ax.set_xticklabels calls ax.xaxis.set_ticklabels which creates a new
Formatter with 

        self.set_major_formatter( FixedFormatter(ticklabels) )

ticklabels are kind of funny, and this is related to the question on
the user's list about setting the location of ticklabels.  The
location and string are determined at draw time by the Locator and
Formatter class, which is why well-intentioned but naive attempts to
control their location and text directly often fail.  One has to set
the locator and formatter, and this is highly configurable and
customizable.  For the most part, I think it works fine.

The one use case brought up on the users list that the framework
doesn't address is the "centering" issue of ticklabels, trying to get
the labels centered between ticks.  I'm mostly -1 on this, and I think
the major/minor hack I suggested can solve this use case fairly
cleanly, but I'm open to counter arguments.  What might be nice,
however, is to add a padx, pady properties to text instances in
general or maybe just ticklabels in specific, that will shift their
horizontal and vertical position by a fixed amount in points.

JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> John, At >4600 lines, axes.py is getting unwieldy, as is the
    Eric> Axes class that makes up the bulk of it.  I propose to
    Eric> reorganize it and split it into at least two files.

    Eric> The main organizational change would separate the
    Eric> functionality that is directly involved in manipulating the
    Eric> axes from the more specific plotting methods.  This could be
    Eric> done, for example, by putting the former in an AxesBase
    Eric> class, and then letting Axes inherit that.  At the very
    Eric> least it would be nice to rearrange the methods so that all
    Eric> the pure Axes manipulation methods are together at the
    Eric> beginning.

    Eric> What do you think?

I don't want overarching ambitions to get in the way of a simple
refactor, but....

I've discussed this with Fernando and Perry on a couple of occasions,
and I think it would be useful to create high level Artists like
LinePlot, ScatterPlot, BarChart, etc, that carried the lines, etc, etc
around with them with useful configuration methods.  The pylab.plot
would be a thin wrapper to Axes.plot which would instantiate a
LinePlot.  A bit like what you recently did for the contour function.

High level plot objects like this would allow us to easily support
things like a FunctionPlot, which always returns the sin(x) at any
given scale, with some configurable, intelligent way to determine the
granularity of sampling at a given scale.

So that is background on the general topic of refactoring axes.py.  As
for your specific suggestion, I have no problem with it.  I have never
had a problem with one large file since emacs and judicious use of
search-forward and search-backward work fine for me.  But I know that
code better than most, and I think your proposed changes would make it
much easier for people approaching the code for the first time to
understand what is going on.  It might also make it clearer how to
pursue the grand refactor down the road.  But I mention it now so you
can think about it while you are working :-)

JDH

On Thursday 30 March 2006 3:44 am, Jouni K Seppanen wrote:
> John Hunter <jdh...@ac...> writes:
> >     Jouni>     label: any string
> >     Jouni>     text: string
> >
> > a 'label' is a property of any matplotlib.artist.Artist (the base
> > class for Line2D, Patch, Text, etc), and is used to attach a string to
> > any object that renders into a figure (including the Figure itself).
> > This is most used for auto-legending
>
> Oh, of course. I was confused by the name "tick labels" for the text
> that accompanies tick marks.
>
> > matplotlib.text.Text.set_text, however, does set the to-be-rendered
> > string for the Text instance.
>
> It doesn't seem to work for tick labels. E.g.
>
>   gca().get_xticklabels()[0].set_text('foo')
>
> has no effect. This is quite understandable, since the text comes from
> a Formatter object. It might be a neat hack to have set_text('foo')
> automatically call set_xticklabels(['foo',...]).

I dont think that can work, since set_xticklabels(['foo',...]) makes its own 
call to set_text('foo').

Eric Firing <ef...@ha...> writes:

> The main organizational change would separate the functionality that
> is directly involved in manipulating the axes from the more specific
> plotting methods.  This could be done, for example, by putting the
> former in an AxesBase class, and then letting Axes inherit that.

IMHO, it would make sense in the long term to make Axes a low-level
class with a well-defined interface, and implement high-level plotting
methods such as bar, boxplot, cohere, hist, specgram and what have you
using that interface outside of Axes. Currently at least some of these
methods "peek under the hood" by doing things like

    if not self._hold: self.cla()

This looks like it will be a pain to maintain if the implementation
details ever change. self._hold could probably be easily replaced by
self.ishold(), but moving the methods to another class would help
ensure that they stay kosher.

-- 
Jouni

John Hunter <jdh...@ac...> writes:

>     Jouni>     label: any string 
>     Jouni>     text: string
>
> a 'label' is a property of any matplotlib.artist.Artist (the base
> class for Line2D, Patch, Text, etc), and is used to attach a string to
> any object that renders into a figure (including the Figure itself).
> This is most used for auto-legending

Oh, of course. I was confused by the name "tick labels" for the text
that accompanies tick marks.

> matplotlib.text.Text.set_text, however, does set the to-be-rendered
> string for the Text instance.

It doesn't seem to work for tick labels. E.g.

  gca().get_xticklabels()[0].set_text('foo')

has no effect. This is quite understandable, since the text comes from
a Formatter object. It might be a neat hack to have set_text('foo')
automatically call set_xticklabels(['foo',...]).

-- 
Jouni

John,

At >4600 lines, axes.py is getting unwieldy, as is the Axes class that 
makes up the bulk of it.  I propose to reorganize it and split it into 
at least two files.

The main organizational change would separate the functionality that is 
directly involved in manipulating the axes from the more specific 
plotting methods.  This could be done, for example, by putting the 
former in an AxesBase class, and then letting Axes inherit that.  At the 
very least it would be nice to rearrange the methods so that all the 
pure Axes manipulation methods are together at the beginning.

What do you think?

Eric

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:

    Jouni> 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.

    Jouni> Yes, 'size' is listed in the output now. However, now it
    Jouni> seems that there are too many things listed:

    Jouni>     label: any string 
    Jouni>     text: string

If I'm reading this right, this has nothing to do with Darren's recent
refactoring.

a 'label' is a property of any matplotlib.artist.Artist (the base
class for Line2D, Patch, Text, etc), and is used to attach a string to
any object that renders into a figure (including the Figure itself).
This is most used for auto-legending

  plot(x1, y1, 'go', label='label x')
  plot(x1, y1, 'rs', label='label y')
  legend()

and legend will "to the right thing"(TM)

In other cases, we might use the label in outputting group information
in SVG output for instance, where we have open and close tags
associated with polygons, etc..

So the label is not necessarily rendered into the figure, although it
might be as the legend example illustrates, but is useful to tag
objects with strings.

matplotlib.text.Text.set_text, however, does set the to-be-rendered
string for the Text instance.  It is right and good that the text
instance has a separate label and text property, though I agree this
might be confusing on a cursory 'setp' or 'getp' introspection.

JDH

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John> It looks like mouse event handling is being swallowed.  It
    John> looks like I'm not getting x-y cursor updates in the
    John> toolbar.

All this was due to an X11 lag, so it can mostly be ignore.  Back into
the dark...

JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> I hope it is not something I have broken...

    Eric> I have never looked at or tested the widgets before.

It looks like mouse event handling is being swallowed.  It looks like I'm
not getting x-y cursor updates in the toolbar.

Looking at the CHANGELOG, I suspect

2006-03-17 Applied sophana's patch to support overlapping axes with
           toolbar navigation by toggling activation with the 'a' key.
           Closes sf patch 1432252 - JDH

And indeed, when I press 'a', the event handling comes back.  

The odd thing is that Axes.__init__ is calling self.set_navigate(True)
(which is what 'a' does in backend_bases.FigureManagerBase.key_press.

So I'm confused, but at least we are on the scent.

JDH

Charlie Moad wrote:
> I shoudl have tried this in the first place.  The
> widgets/radio_buttons.py example doesn't work at all for me.  In fact
> quite a few are broken.
> 
> buttons.py
> check_buttons.py
> radio_buttons.py
> sliders.py
> 
> Do these work for anybody with svn?

They don't work for me with GtkAgg, so it is not a Tk-specific backend 
problem.

I hope it is not something I have broken...

I have never looked at or tested the widgets before.

Eric

> 
> - Charlie
> 
> On 3/29/06, John Hunter <jdh...@ac...> wrote:
> 
>>>>>>>"Charlie" == Charlie Moad <cw...@gm...> writes:
>>
>>    Charlie> Before I bang my head against the wall I figured I would
>>    Charlie> check the list.  I have a script that uses the radio
>>    Charlie> button widget in a TkAgg.  This worked not too long ago,
>>    Charlie> but now it is not responding to clicks with the latest
>>    Charlie> matplotlib.  Has there been changes recently to the TkAgg
>>    Charlie> backend that would affect this?
>>
>>It doesn't look like it:
>>
>>peds-pc311:~/mpl> svn log lib/matplotlib/backends/backend_tkagg.py
>>------------------------------------------------------------------------
>>r2139 | dsdale | 2006-03-11 18:11:40 -0600 (Sat, 11 Mar 2006) | 7
>>lines
>>
>>added **kwargs to all backend_*.print_figure
>>methods to provide papertype kwarg to backend_ps
>>
>>fixed landscape orientation for usetex option
>>
>>added subprocess module from python-2.4
>>
>>------------------------------------------------------------------------
>>r1889 | cmoad | 2005-11-30 14:05:05 -0600 (Wed, 30 Nov 2005) | 2 lines
>>
>>assume png on no extension save
>>
>>------------------------------------------------------------------------
>>r1591 | cmoad | 2005-08-08 09:46:47 -0500 (Mon, 08 Aug 2005) | 2 lines
>>
>>almost have tkagg blitting working
>>
>>------------------------------------------------------------------------
>>r1586 | jdh2358 | 2005-08-05 11:13:26 -0500 (Fri, 05 Aug 2005) | 2
>>lines
>>
>>small cursor fix
>>
>>------------------------------------------------------------------------
>>r1584 | cmoad | 2005-08-04 14:13:08 -0500 (Thu, 04 Aug 2005) | 2 lines
>>
>>Added blit to FigureCanvasTkAgg, but it does not account for the bbox
>>yet.
>>
>>
>>
>>Maybe it is a tk version problem?
>>
>>JDH
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I shoudl have tried this in the first place.  The
widgets/radio_buttons.py example doesn't work at all for me.  In fact
quite a few are broken.

buttons.py
check_buttons.py
radio_buttons.py
sliders.py

Do these work for anybody with svn?

- Charlie

On 3/29/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
>     Charlie> Before I bang my head against the wall I figured I would
>     Charlie> check the list.  I have a script that uses the radio
>     Charlie> button widget in a TkAgg.  This worked not too long ago,
>     Charlie> but now it is not responding to clicks with the latest
>     Charlie> matplotlib.  Has there been changes recently to the TkAgg
>     Charlie> backend that would affect this?
>
> It doesn't look like it:
>
> peds-pc311:~/mpl> svn log lib/matplotlib/backends/backend_tkagg.py
> ------------------------------------------------------------------------
> r2139 | dsdale | 2006-03-11 18:11:40 -0600 (Sat, 11 Mar 2006) | 7
> lines
>
> added **kwargs to all backend_*.print_figure
> methods to provide papertype kwarg to backend_ps
>
> fixed landscape orientation for usetex option
>
> added subprocess module from python-2.4
>
> ------------------------------------------------------------------------
> r1889 | cmoad | 2005-11-30 14:05:05 -0600 (Wed, 30 Nov 2005) | 2 lines
>
> assume png on no extension save
>
> ------------------------------------------------------------------------
> r1591 | cmoad | 2005-08-08 09:46:47 -0500 (Mon, 08 Aug 2005) | 2 lines
>
> almost have tkagg blitting working
>
> ------------------------------------------------------------------------
> r1586 | jdh2358 | 2005-08-05 11:13:26 -0500 (Fri, 05 Aug 2005) | 2
> lines
>
> small cursor fix
>
> ------------------------------------------------------------------------
> r1584 | cmoad | 2005-08-04 14:13:08 -0500 (Thu, 04 Aug 2005) | 2 lines
>
> Added blit to FigureCanvasTkAgg, but it does not account for the bbox
> yet.
>
>
>
> Maybe it is a tk version problem?
>
> JDH
>