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