Re: [matplotlib-devel] patch for adding manual label location selection to clabel

[John H. <jd...@gm...>]

On Fri, Jul 18, 2008 at 2:32 PM, David M. Kaplan <Dav...@ir...> wrote:

> Well, yeah.  I think this would mean a lot of the same code in many
> backends.  I also like the idea of a deeper hierarchy with a
> FigureCanvasUserInterface class that inherits FigureCanvasBase but adds
> functional start/stop_loop_events because it would allow for a simple
> cbook test for a working user interface:
> isinstance(mycanvas,FigureCanvasUserInterface)

I'm not sure I see where the redundant code is coming in.  In envision
the base class doing nothing in start_event_loop and stop_event_loop
which solves the problem for the non-UI backends, and all the UI
backends will have to be specialized to deal with their own event
loops.  Basically, we would need to provide implementations for gtk,
tk, wx and qt (and maybe qt4?) since these are the four backends that
are actually maintained.   Perhaps I am overly squeamish, but I am
uncomfortable with a default UI implementation here anyhow.

This is the paradigm we have used for the canvas draw_idle method and
it has worked fine.  If we get consensus on this, I think we can bang
out the four methods quickly.  tk requires nothing special and can be
based on the current sleep implementation.  I can help with gtk if
need be.  Paul has already done wx.  qt anyone?

Also, are the names stop_event_loop and stop_event_loop good choices?
I find them confusing because I associate them with the UI event loop
which will always be running.  Something like
wait_start and wait_stop is more intuitive to me.

> A deeper hierarchy won't help the inheritance problem for GTKAgg though.

I believe this will solve the problem, because FigureCanvasGTK is
inherited first, so GTKAgg will get the specialized method.  According
to Guido at
http://www.network-theory.co.uk/docs/pytut/MultipleInheritance.html

  The only rule necessary to explain the semantics is the resolution
rule used for class attribute
  references. This is depth-first, left-to-right. Thus, if an
attribute is not found in DerivedClassName,
  it is searched in Base1, then (recursively) in the base classes of
Base1, and only if it is not
  found there, it is searched in Base2, and so on.