matplotlib-devel Mailing List for matplotlib

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:
 Ted> John, I had some questions about this resize work. Here is
 Ted> the code for resize from backend_gtk.py:
 Ted> def resize(self, w, h): 'set the drawing area size in
 Ted> pixels' winw, winh = self.parent.parent.get_size() tmp, tmp,
 Ted> myw, myh = self.allocation padw = winw-myw padh = winh-myh
 Ted> self.parent.parent.resize(w+padw, h+padh)
 Ted> I'm a little concerned about this implementation. It looks
 Ted> like the widget is telling it's parent's parent to resize.
 Ted> Doesn't this mean that the ability of the widget to be used
 Ted> as a modular component is reduced because this code requires
 Ted> a certain parent child relationship?
Oops, you're right. Good catch. This implementation will fail for
some widget packings, eg a canvas in a scrolled window...
 Ted> I think it's fairly important that a widget have only very
 Ted> minimum interactions with it's parent. Is there some way
 Ted> this could be implemented that doesn't require the child
 Ted> widget to be calling methods on the parent?
 Ted> If I understand the basic premise you've outlined below, you
 Ted> want a resize in the child (the drawing widget) to cause the
 Ted> parent window to resize. Only the parent can figure out what
 Ted> it's size needs to be (since it knows about it's margins,
 Ted> toolbars, etc). On the surface, it seems like there are two
 Ted> ways to handling this: 1) Tell the window to resize the
 Ted> canvas. The window can use it's own layout classes, etc and
 Ted> correctly resize itself and the canvas. 2) Tell the canvas
 Ted> to resize and have this trigger a window resize.
 Ted> I think the first option is much cleaner. However, if that
 Ted> isn't possible, I suggest that we do something like this:
Right, we don't need a resize method. As you suggest, all we need
is a way to tell the canvas and its parent(s) to auto_adjust itself to
accommodate the figure (using the width, height and dpi settings ....)
Then whenever fig.set_dpi or fig.set_figsize_inches or
fig.set_figsize_pixels (to be added) is called, we could call
 self.canvas.update_size()
if we can figure out the right way to propagate up containment chain.
The update_size method will have to send a signal to the parent, but
how this is done can be backend dependent. I think the logic in my
first implementation is still correct if we replace self.parent.parent
(which as you note makes certain parent/child assumptions) with the
gtk.Window the canvas resides in because it sets it computes the width
and height of all the other widgets in the canvas by subtracting the
canvas width/height from the window width/height.
 winw, winh = self.gtkwin.get_size()
 tmp, tmp, myw, myh = self.allocation
 padw = winw-myw
 padh = winh-myh
 self.gtkwin.resize(w+padw, h+padh)
Of course this would require that the canvas user sets gtkwin. Other
than for the philosophical reason that the child calls methods on the
parent, do you still think this implementation is problematic? I
personally don't find it problematic, but I'm willing to be corrected
:-) Of course, in QT you could handle it anyway you want, eg using
signals to the parent.
If you can sketch a cleaner implementation that makes more sense let
me know. Since only GTK has an implementation currently and it is
broken, and no mpl code is currently using the resize function, the
field is wide open.
Thanks,
JDH

John,
I had some questions about this resize work. Here is the code for resize 
from backend_gtk.py:
 def resize(self, w, h):
 'set the drawing area size in pixels'
 winw, winh = self.parent.parent.get_size()
 tmp, tmp, myw, myh = self.allocation
 padw = winw-myw
 padh = winh-myh
 self.parent.parent.resize(w+padw, h+padh)
I'm a little concerned about this implementation. It looks like the widget 
is telling it's parent's parent to resize. Doesn't this mean that the 
ability of the widget to be used as a modular component is reduced because 
this code requires a certain parent child relationship?
I think it's fairly important that a widget have only very minimum 
interactions with it's parent. Is there some way this could be 
implemented that doesn't require the child widget to be calling methods on 
the parent?
If I understand the basic premise you've outlined below, you want a resize 
in the child (the drawing widget) to cause the parent window to 
resize. Only the parent can figure out what it's size needs to be (since 
it knows about it's margins, toolbars, etc). On the surface, it seems like 
there are two ways to handling this:
1) Tell the window to resize the canvas. The window can use it's own 
layout classes, etc and correctly resize itself and the canvas.
2) Tell the canvas to resize and have this trigger a window resize.
I think the first option is much cleaner. However, if that isn't possible, 
I suggest that we do something like this:
- Tell the canvas to resize. It should resize itself and emit some type of 
'plotCanvasResize' signal (GUI callback).
- When the window is originally constructed, it would attach a method on 
the window to this signal so that we basically get the same behavior as 1) 
above. Telling the canvas to resize emits the signal which calls the 
window method to do the real resizing. The canvas widget never knows that 
it's part of the window at all.
Of course this assumes that we have access to signal/slot (in Qt terms) 
systems in the Python layer. I'd also suggest that we stay away from 
calling it 'resize' since most GUI toolkits already have resize 
methods/attributes that mean very specific things.
Thoughts?
Ted
> There is a new method in the figure canvas in CVS that I would like
> the maintainers of the various GUI backends to implement
>
> class FigureCanvasYourBackend
>
> def resize(self, w, h):
> """
> set the canvas size in pixels
> """
> pass
>
> This should set the canvas (not window) size and trigger a GUI resize
> event so that the window is resized accordingly. There is a reference
> implementation in backend_gtk.py. You should be able to lift the
> logic for computing the new canvas size directly from that code.
>
> Among other things, this will allow better control of the canvas size
> from a script or shell. Eg, the following works with GTKAgg in an
> interactive session:
>
> In [1]: fig = figure()
> In [2]: fig.set_figsize_inches(3,4,forward=True)
> In [3]: fig.canvas.resize(500,600)
>
> Ie, you can set the canvas size either in pixels or inches depending
> on which method you choose.
>
> Also, I added a new connect signal 'resize_event' that triggers a
> backend_bases.ResizeEvent on a canvas.resize. You should call
>
> self.resize_event()
>
> from the part of your code that handles GUI configure events (see for
> example the GTK and GTKAgg backends). Note depending on your toolkit,
> you may not want to call this from the FigureCanvas.resize method.
> Eg, in GTK* calling "canvas.resize" triggers a call to
> canvas.configure_event, which in turn sets the new figure size
> properties and once all this is done, calls canvas.resize_event.
>
> Here is some test code
>
> from pylab import figure, connect, show
> fig = figure()
> def resize(event):
> print 'resize canvas', event.width, event.height
>
> connect('resize_event', resize)
> show()
>
> Checking in lib/matplotlib/backend_bases.py;
> /cvsroot/matplotlib/matplotlib/lib/matplotlib/backend_bases.py,v <-- 
> backend_bases.py
> new revision: 1.69; previous revision: 1.68
>
> Thanks!
> JDH
>
>
Ted Drain Jet Propulsion Laboratory ted...@jp... 

On 10/7/05, Robert Kern <rk...@uc...> wrote:
>
> John Hunter wrote:
> >>>>>>"Paul" =3D=3D Paul Barrett <peb...@gm...> writes:
> >
> > Paul> I have data that has error bars and upper limits. (Actually
> > Paul> they are lower limits, since the Y axis is in stellar
> > Paul> magnitudes and is inverted.) My suggestion is use a negative
> > Paul> error value to indicate a limit in which case an arrow would
> > Paul> be drawn, instead of an error bar. This feature would only
> > Paul> apply to the case of asymmetric error bars and not to the
> > Paul> symmetric case. I can produce a patch if this suggestion is
> > Paul> agreeable.
> >
> > I certainly don't have a problem with this and would be happy to
> > include these extensions to the errorbar function. I wonder if the
> > arrow is the best indicator for a limit, though I can't think of a
> > better one at the moment. Also, does this handle limits in either
> > direction (up or down) as well as left to right?
>
> Arrows are often used to indicate error bars which end outside of the
> displayed area of the plot. I would also recommend against using
> negative error values to indicate limits instead of errors. It smells of
> FORTRAN. :-)
Yes, it does smell of FORTRAN. However, my motive for suggesting negative
error values is that it allows the user to specify the length of the limit
arrow and numeric arrays to be used for input. The other option would be to
use a string, e.g.'limit(2)', as a marker. This will complicate the
implementation, but that is less of a concern to me than usability. I think
that the ability to specify the length of the arrow is needed. This could b=
e
an optional parameter though. I'm open to suggestions.
Limits should probably be implemented by a separate
> object/function/whatever.
>
In astronomy, limit data is often associated with data having large error
bars, i.e. they go hand-in-hand. So, a separate function would essentially
duplicate the error bar functionality. I see no need for this duplicity.
-- Paul

On 10/7/05, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Paul" =3D=3D Paul Barrett <peb...@gm...> writes:
>
> Paul> I have data that has error bars and upper limits. (Actually
> Paul> they are lower limits, since the Y axis is in stellar
> Paul> magnitudes and is inverted.) My suggestion is use a negative
> Paul> error value to indicate a limit in which case an arrow would
> Paul> be drawn, instead of an error bar. This feature would only
> Paul> apply to the case of asymmetric error bars and not to the
> Paul> symmetric case. I can produce a patch if this suggestion is
> Paul> agreeable.
>
> I certainly don't have a problem with this and would be happy to
> include these extensions to the errorbar function. I wonder if the
> arrow is the best indicator for a limit, though I can't think of a
> better one at the moment. Also, does this handle limits in either
> direction (up or down) as well as left to right?
>
Yes, a negative value for the upper error bar will indicate an upper limit
and vice versa for the lower error bar value. The same goes for left and
right limits.
Note that this enhancement will only affect asymmetric error bars and not
symmetric ones, since the latter case doesn't make much sense to me.
-- Paul

>>>>> "Kilian" == Kilian Hagemann <hag...@eg...> writes:
 Kilian> Hmm, I must admit I knew nothing about figures when I
 Kilian> posted. But now that I've done some homework, I see that
 Kilian> using Figure.legend is suboptimal as well because it can
 Kilian> neither resize the axes accordingly nor place outside
 Kilian> legends for each subplot automatically.
Hey Killian,
OK, I am happy to include this because I think the auto-resizing
capability is useful (eg following the colorbar model). Now that you
are aware of the figure legend, please take a look at your self.parent
handling because parent can be an Axes or a Figure. You will want to
check for isaxes before calling 
 self.parent.get_position()
and associated functions.
Also, as a matter of style and efficiency, I prefer to avoid multiple
function calls in lines like
 figwidth = self.get_figure().get_figwidth()*float(self.get_figure().get_dpi())
 figheight = self.get_figure().get_figheight()*float(self.get_figure().get_dpi())
rather
 fig = self.get_figure()
 dpi = fig.get_dpi()
 figheight = fig.get_figheight()*dpi
 figwidth = fig.get_figwidth()*dpi
dpi is already a float....
But even more pithily <wink>
 w, h = fig.canvas.get_width_height()
Also, although these aren't written down anywhere (wiki entry needed
so feel free to make one!) the matplotlib coding conventions are
 classes: UpperCase
 functions and methods: underscore_separated
 attributes and variables : lower of lowerUpper
so vars like space_needed should be spaceneeded or spaceNeeded. Ditto
for the fudge_* vars and new_aw and so on.
Finally, I think your patch against your own tree, because it contains
lines like
- 'upper outside right' : 11,
+ 'upper outside right' : 11, # these only make sense with axes legends
Eg, it is removing things that do not exist in matplotlib CVS -- make
sure you apply diff against mpl CVS and not your own tree !
JDH

>>>>> "Kilian" == Kilian Hagemann <hag...@eg...> writes:
 Kilian> Dear developers, On Monday I sent an email to the
 Kilian> matplotlib-users list
 Kilian> (http://sourceforge.net/mailarchive/forum.php?thread_id=8391378&forum_id=33405)
 Kilian> asking if it was possible to have a 'centered' axis.
 Kilian> As I received no reply and couldn't find any other info, I
 Kilian> assume that this functionality is not present in
 Kilian> matplotlib-0.84. Am I right or is there a way?
Sorry. I answered this question quite recently in another thread
http://sourceforge.net/mailarchive/message.php?msg_id=13146574 which
shows a hackish way that doesn't give you ticks
 Kilian> Cause if the lines of the x and y axis can only be plotted
 Kilian> on the lower/left edge of the axes/subplot I'd be keen to
 Kilian> enhance the code to make this flexible. Seems like I'd be
 Kilian> targeting axes.py and axis.py, but I'd also have to know
 Kilian> how this is done in Matlab to keep compatibility (I did
 Kilian> Matlab 6 years ago and don't remember anything).
This would be a very nice feature and one I and others have been
wanting for a long time. axes.py and axis.py are the right modules to
look into. I don't know how matlab does it; it is a good idea to look
into this for inspiration and API compatibility but we don't need to
follow their implementation slavishly if there is a better one.
I don't think it would be a lot of work to do this. You will want to
make the edgecolor and facecolor of the axes patch the same as
indicated in the thread above, and the add a Line2D to the XAxis and
YAxis classes, and support placing them at an arbitrary location. The
only tricky bit is that the axis classes work with some of the darker
matplotlib transformation magic, which is hard for most people to
understand because I do transformations in a nonstandard way.
Nonetheless, they are reasonably well documented in the class
documentation.
I think it would be useful to support multiple axis lines per axes (eg
two y scales). Chaco makes the axis a line property which is fairly
different from the matplotlib approach but makes it easy to do things
like drag a line from one axes to another with the axis coming along
with it. Not sure if this is the right approach or not.
Good luck! Please keep us posted with implementation ideas and feel
free to ask a lot of questions.
JDH

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <peb...@gm...> writes:
> 
> Paul> I have data that has error bars and upper limits. (Actually
> Paul> they are lower limits, since the Y axis is in stellar
> Paul> magnitudes and is inverted.) My suggestion is use a negative
> Paul> error value to indicate a limit in which case an arrow would
> Paul> be drawn, instead of an error bar. This feature would only
> Paul> apply to the case of asymmetric error bars and not to the
> Paul> symmetric case. I can produce a patch if this suggestion is
> Paul> agreeable.
> 
> I certainly don't have a problem with this and would be happy to
> include these extensions to the errorbar function. I wonder if the
> arrow is the best indicator for a limit, though I can't think of a
> better one at the moment. Also, does this handle limits in either
> direction (up or down) as well as left to right?
Arrows are often used to indicate error bars which end outside of the
displayed area of the plot. I would also recommend against using
negative error values to indicate limits instead of errors. It smells of
FORTRAN. :-)
Limits should probably be implemented by a separate
object/function/whatever.
-- 
Robert Kern
rk...@uc...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

>>>>> "Paul" == Paul Barrett <peb...@gm...> writes:
 Paul> I have data that has error bars and upper limits. (Actually
 Paul> they are lower limits, since the Y axis is in stellar
 Paul> magnitudes and is inverted.) My suggestion is use a negative
 Paul> error value to indicate a limit in which case an arrow would
 Paul> be drawn, instead of an error bar. This feature would only
 Paul> apply to the case of asymmetric error bars and not to the
 Paul> symmetric case. I can produce a patch if this suggestion is
 Paul> agreeable.
I certainly don't have a problem with this and would be happy to
include these extensions to the errorbar function. I wonder if the
arrow is the best indicator for a limit, though I can't think of a
better one at the moment. Also, does this handle limits in either
direction (up or down) as well as left to right?
JDH

Dear developers,
On Monday I sent an email to the matplotlib-users list 
(http://sourceforge.net/mailarchive/forum.php?thread_id=8391378&forum_id=33405)
asking if it was possible to have a 'centered' axis.
As I received no reply and couldn't find any other info, I assume that this 
functionality is not present in matplotlib-0.84. Am I right or is there a 
way?
Cause if the lines of the x and y axis can only be plotted on the lower/left 
edge of the axes/subplot I'd be keen to enhance the code to make this 
flexible. Seems like I'd be targeting axes.py and axis.py, but I'd also have 
to know how this is done in Matlab to keep compatibility (I did Matlab 6 
years ago and don't remember anything).
-- 
Kilian Hagemann
Climate Systems Analysis Group
University of Cape Town
Republic of South Africa
Tel(w): ++27 21 650 2748

On Thursday 06 October 2005 23:52, you pondered:
>
> Are you aware of Figure.legend, which is designed to do what you
> describe (place a legend outside the axes). 
Hmm, I must admit I knew nothing about figures when I posted. But now that 
I've done some homework, I see that using Figure.legend is suboptimal as well 
because it can neither resize the axes accordingly nor place outside legends 
for each subplot automatically.
> See also 
> examples/figlegend_demo.py. I don't think your patch made it through
> (at least I couldn't read it) but if there are extra features you need
> (like auto-resizing the axes) I think these will be best placed in
> Figure.legend.
Somehow my patch got truncated. Here it is again. I still think that 
legends.py is the place to have the resizing code as in this way you can do 
it with arbitrary number of subplots & layouts. In figure.py I would imagine 
this to be difficult with arbitrary number of axes.
Oh, by the way there was a request sometime ago for an automated way to place 
legends outside:
http://sourceforge.net/mailarchive/message.php?msg_id=11106725
Have a look at the patch and tell me what you think.
-- 
Kilian Hagemann
Climate Systems Analysis Group
University of Cape Town
Republic of South Africa
Tel(w): ++27 21 650 2748