|
From: Benjamin R. <ben...@ou...> - 2013-08-02 19:55:01
|
On Fri, Aug 2, 2013 at 3:32 PM, Eric Firing <ef...@ha...> wrote: > On 2013/08/02 8:55 AM, Drain, Theodore R (392P) wrote: > > Thanks - we'll look into that. We might also see how hard it would > > be to implement an update or refresh method on the legend that could > > be called when the lines change to keep the legend in sync. Seems > > like the legend should own that functionality since it set up the > > mapping between the lines and what it's displaying... > > I agree entirely. It would be logical for the legend to either have a > manual refresh method, or perhaps to be coupled to its targets the way a > colorbar is coupled to its mappable, tracking it automatically. The > Legend is a very complex beast, however, so I suspect this is a real > project. > > Mike and I discussed this at the recent conference. What makes ScalarMappable different from other artists is that it has attribute caching and it has callback mechanisms for changes to certain attributes. This is why colorbar can change with its image. These features needs to be better generalized and cleaned up, and then applied to *all* attributes. Another issue is that the artist objects contained in the legend are created from the artist objects that it represents -- at the time of legend creation. All color, linestyle marker, etc. attributes are copied rather than referenced in the artists in the legend. Therefore, any changes to either doesn't impact the other, unfortunately. So, there are two approaches to solve this. 1) implement a generic, efficient callback mechanism for attributes (and proper caching to reduce unneeded dispatches) and have the legend object register callbacks for any changes in the legend entries. 2) have a mechanism for some sort of shared attributes. Just thinking out loud... wishing I had the time to actually implement my ideas... Cheers! Ben Root |