Nice, simple, elegant, but it doesn't quite match what I had
> in mind for axes. I was thinking that the place to put the
> hook call is inside the draw() method, so it can take
> advantage of the intial work done there: getting a cached
> renderer, checking for visibility. Maybe this doesn't
> matter.
Well for these two pieces, perhaps the method should look like
def draw(self, renderer=None, **kwargs):
if renderer is None:
renderer = self._cachedRenderer
if renderer is None:
raise RuntimeError('No renderer defined')
if not self.get_visible(): return
for func in self.before_draw_hook.ordered_values():
func(self, renderer)
self._draw(renderer, **kwargs)
for func in self.after_draw_hook.ordered_values():
func(self, renderer)
and perhaps the renderer caching should be done at the figure level
if renderer is None:
renderer = self.figure._cachedRenderer
> Also, looking at backend_bases, I can't figure out where
> this goes. There is a RendererBase class, but it doesn't
> have a draw method. And there is a FigureCanvasBase, but
> its draw method is overridden by each backend. What am I
> missing?
I meant artist.Artist.draw -- sorry for the bad info.
> and have def register_before_draw(self, name, func): if
> self.before_draw_hook is None: self.before_draw_hook =
> OrderedDictionary() self.before_draw_hook.append(name, func)
We also need a connectionid for connecting and disconnecting or
something like it.
> Looking at the axes draw method, I am wondering whether a
> more general application of an OrderedDictionary (or
> ListDict, or whatever) wouldn't be a better approach. Why
> should there be before_draw_hook, draw, and after_draw_hook,
> with a big list generation and sorting operation at draw
> time? Could everything be done by having artists register
> all draw-time functions in a single ListDict, with
> sufficient ordering information to keep everything straight?
> That's pretty vague, and there is a lot I don't
> understand--but it just seems like there is an opportunity
> here for simplifying the overall structure with improved
> flexibility and no loss of speed. (Again, some kind of
> result-caching and need-for-recomputation-signalling would
> be needed.)
This is interesting -- the devil will be in the details. Eg when one
artist changes it's zorder, the whole connection hierarchy will need
to be redone, which is currently accomplished by doing the sort w/
every draw. Your way would be faster since we would only need to do
the ordering when the zscore changes, or when new artists are added,
and not with every draw. But it might become difficult to manage
resorting if users have added their own hooks. And then it wouldn't
really be a before draw hook but a draw hook....
Actually, if we go this route, we may need to have one registry for
user hooks, and another registry from internal calls. So any artist
could support drawing other artists, eg Lines and Labels register with
Ticks register which registers with an Axis which registers with an
Axes which registers with a Figure. Of course at this point we are
talking about a major architectural change and so there would need to
be some clear utility, and I'm not sure what it is. The current
design assumes an artist knows how to draw it's child artist, the one
you are proposing it seems assumes the child artist knows how to
insert itself into the parent.
JDH