On Mon, Oct 25, 2010 at 9:40 AM, Michael Droettboom <md...@stsci.edu> wrote: > On 10/23/2010 06:05 PM, David Carmean 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. > It's great to see someone working on this. Similar ideas have been > thrown around since at least as long as I "joined the party" in 2007 > (search the e-mail archives for "Traits"). I like your approach because > it should allow for a tighter integration of Traits, while at the same > time not adding Traits as a dependency. It just might be the elusive > middle ground that prevented us from really going forward way back when. > > Mike
+1 on Mike's middle-ground idea. In case you haven't seen it, decorators are presently used to allow Aritist.draw to make a raster mode switch for a MixedModeRenderer. It's really a generic per-artist before/after draw signal implemented for that single purpose. This could potentially be refactored if there's a new signaling system in place. -Eric ------------------------------------------------------------------------------ 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
