On Sat, Oct 23, 2010 at 5:05 PM, David Carmean <d...@halibut.com> 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 ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
