matplotlib-devel Mailing List for matplotlib

On Sun, Oct 24, 2010 at 10:35:03AM -0500, Ryan May wrote:
> On Sat, Oct 23, 2010 at 5:05 PM, David Carmean <dl...@ha...> wrote:
[snip]
> > I've spent a few hours this weekend doing some meta-monkey-patching--
> > using __getattribute__ to decorate the setters on-the-fly to invoke
> > callbacks.process(*args) after the changes.  I have a few more quick
> > hacks to try before I'm ready to decide on a production-ready strategy.
> >
> > So my question today is: is anyone interested in discussing these
> > ideas and how to implement them?
> 
> I'm interested. I was just noticing a need for the signals to simplify
> some interactive stuff I was doing. I'm not wild about using the
> current incarnation of the CallbackRegistry, since it doesn't allow
> you to add signals after you create the object. Also, there are only
> global signals, you can't connect to a specific object (unless you
> were planning on each object having its own registry?). When I was
> considering this yesterday, I was looking at these:
> 
> http://code.activestate.com/recipes/87056/
> http://pydispatcher.sourceforge.net/
> 
> Also, had you given any thought to using decorators to note methods
> that emit a certain signal, or to connect one method to a given
> signal?
I've gone through the same thought process. I do plan to add a 
CallbackRegistry.add_signals method; I am giving each instance 
it's own registry instance (axes.Axes already does this); and I 
am using decorators. 

[Putting this back on list after I mistakenly took it off.]
On Fri, Oct 22, 2010 at 11:45 PM, Michiel de Hoon <mjl...@ya...> wrote:
> Hi Ryan,
>
> Thanks for your reply.
>
> --- On Mon, 10/18/10, Ryan May <rm...@gm...> wrote:
>> In the course of adding the animations, I also
>> added a "close_event" to the other backends, so that the
>> timers would stop on figure close and the users wouldn't
>> get weird messages. Did you happen to add this?
>
> I added the close_event to the Mac OS X backend today.
>
>> I'm not sure you can move this to figure.draw(renderer),
>> since that's going to draw *everything*.
>
> One solution is to add an .animation attribute to the Figure class, which is None by default (for non-animated drawing).
>
> Roughly, the code should then look as follows:
>
> In the Animation class, the _step method sets Figure.animation and lets the canvas know that it should redraw itself:
>
>  def _step(self, *args):
>    try:
>      framedata = self.frame_seq.next()
>      self.figure.animation = self, framedata
>      self.figure.canvas.draw_idle()
>      return True
>    except StopIteration:
>      return False
>
> Note that no actual drawing is done here.
>
> In the Figure class, the draw method should then become:
>
>  def draw(self, renderer):
>    if self.animation:
>      animation, framedata = self.animation
>      animation._draw_next_frame(framedata, animation._blit)
>      return
>    # otherwise, draw as usual.
>
> Then all actual drawing is done from inside Figure.draw, which is what the Mac OS X backend needs.
>
> How does this look? If this looks OK, I can try to work out the details and send you the modified code so you can check it out.
I'm not completely wild about it, because it just feels wrong to put
something specific to animation inside figure. The problem we're
trying to solve here is biltting, so is there some way we can improve
how blitting is handled? This would also be a time where we could
(possibly) simplify/improve the blitting API. Do any of the current
uses of blitting work with the MacOSX backend? If those *do* work,
then I'm doing something wrong and need to rework animations. If not,
then we need to find a way to make it so blitting can work in general.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Sat, Oct 23, 2010 at 5:05 PM, David Carmean <dl...@ha...> wrote:
>
> As I blurted on -users, I'm thinking lately about callbacks in the
> non-GUI portions of the libraries--mostly Artist and subclasses.
> I'm curious if anybody else has been thinking about them?
>
> Ideally, I'd like to see the following:
>
>  All of the Artist subclasses, and anything else that might belong to
> a Figure, would be updated to use/add cbook.CallbackRegistry callbacks
> (weakref = good thing).
>
>  In addition to emulating/replacing the simplistic 'pchanged' callback
> with a signal of that same name, there would be a signal named after each
> setter method, and said methods fire off their eponymous signal after they
> modify the property.
>
>  There should be some way to rate-limit or temporarily block individual
> signals or callback connections.
>
>  The various constructors, etc, would be modified to "subscribe" to
> the 'pchanged' signal of all children, such that even if a particular
> object in the "middle" of a figure heirarchy does nothing with the
> signal, a sort of a global 'pchanged' signal propagates up to the top
> object (FigureManager, Canvas, Figure, something).
>
> My current Use Case for these features is in experimenting with different
> Artist styles (Text styles/fonts, marker styles/sizes, etc), and I'm tired
> of calling canvas.draw() all the time :)  But also, I'm working on a
> GUI to do the same (traits UI), and want to tie both layers of the model
> together with callbacks to speed up the experimenting.
>
> I've spent a few hours this weekend doing some meta-monkey-patching--
> using __getattribute__ to decorate the setters on-the-fly to invoke
> callbacks.process(*args) after the changes.  I have a few more quick
> hacks to try before I'm ready to decide on a production-ready strategy.
>
> So my question today is: is anyone interested in discussing these
> ideas and how to implement them?
I'm interested. I was just noticing a need for the signals to simplify
some interactive stuff I was doing. I'm not wild about using the
current incarnation of the CallbackRegistry, since it doesn't allow
you to add signals after you create the object. Also, there are only
global signals, you can't connect to a specific object (unless you
were planning on each object having its own registry?). When I was
considering this yesterday, I was looking at these:
http://code.activestate.com/recipes/87056/
http://pydispatcher.sourceforge.net/
Also, had you given any thought to using decorators to note methods
that emit a certain signal, or to connect one method to a given
signal?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On 10/22/10 7:16 PM, Michael Droettboom wrote:
> On 10/22/2010 05:45 PM, Russell E. Owen wrote:
>> I'm curious when the next release of matplotlib is due.
>>
>> My application is suffering badly from the issue that an incorrect font
>> cache will cause matplotlib to fail (the application mysteriously exits
>> partway through startup until the user deletes the font cache).
>>
>> That problem is allegedly fixed on the trunk and I'm trying to decide
>> how best to deal with it. Depending on the timing of 1.0.1 I can decide
>> whether it's worth putting in my own workaround, bundling a prerelease
>> version of matplotlib or just waiting for the official release.
> I'm not sure what the timeframe is on 1.0.1.
>
> What problem with the cache are you referring to? I'm aware of a
> problem where if some fonts are moved or removed after the cache is
> created matplotlib will crash (and this problem is fixed in the trunk),
> but is that really a problem in everyday practice? I'm just curious --
> if there's another issue with the cache that I'm not aware of, I'd like
> to fix it.
>'
We've been running into problems in Sage that seem to occur because font 
caches from 1.0.0 make old versions of matplotlib die. I haven't seen 
the problem myself, but several Sage developers have put in quite a bit 
of time in diagnosing the problem. In the end, I think they wrote a 
patch to do custom MPLCONFIGDIR for different versions of matplotlib in 
different versions of Sage.
I'm CCing sage-devel, in case one of the sage devs that ran into 
problems wants to comment.
Thanks,
Jason
--
Jason Grout