Re: [matplotlib-devel] Another try at interactive gui thread

[John H. <jdh...@ac...>]

>>>>> "Baptiste" == Baptiste Carvello <bap...@al...> writes:

    Baptiste> I know the patch is intrusive, though maybe not as much
    Baptiste> as it looks (everything except protect_mutex.py is
    Baptiste> pretty trivial). I didn't expected it to be accepted
    Baptiste> right away, I see it more as a contribution to the whole
    Baptiste> gui thread discution.

    Baptiste> As for gui_thread, I looked at it last year, I just
    Baptiste> remember I didn't like that code that much. Maybe I
    Baptiste> should get another look...

Most of what I've heard of gui thread (caveat, the situation may be
different now but this was the last I heard) was that the code was
hairy, required scipy distutils to build, was wx specific and had
problems that required significant work to fix.  In that context, a
patch, even an intrusive one, that allowed gtk* and wx* to work from
an arbitrary python shell would be most welcome.  While I think
ipython is the one true shell, there are many other shells in
existence and that won't change.  If for example, this patch allowed
gtk* to be used from within IDLE or pycrust in addition to the
standard python shell, that would be a big win.

The problem we need to solve is substantially easier than the one
gui_thread wants to solve, if I understand the issues correctly.  gui
thread enables you to interact with general wx apps from a general
python shell.  We want gtk* and wx* backends to work from a general
python shell.  If this patch addresses that, it's worth a close look.
Baptiste, have you have a chance to test with other shells?  Would
your patch break gtk* or wx* under ipython?  Does it work in IDLE
and/or pycrust?  Do you have any ideas on how this would affect
performance?  Obviously it adds some function call overhead -- with
collections the cases where there are large numbers of calls to the
backend renderers is reduced.

Another thought spoken as a threading newbie: could this be done more
simply by, eg subclassing RendererGTK and automating the protect
wrapping.  This latter approach would satisfy a couple of points: it
would not be intrusive in the base class, could be made optional via
interactive setting or rc, and would not adversely impact performance
when it was not needed (on my quick read of the patch, it looks like
the last point is already handled by the call)

  if is_interactive():
      import_protect()


I'll give your patches a test-drive.  Perhaps Steve could also comment
on the gtk changes.

JDH