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

[Fernando P. <Fer...@co...>]

John Hunter wrote:
>>>>>>"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.

I certainly have never been a fan of digging too deep into gui_thread myself, 
I admit that much :)  Last time I looked at the code, I got a bit scared.  On 
the other hand, Prabhu recently did a bunch of work on it, so it may be 
cleaner/better, I just don't know.

And as I said, I really was not speaking from the ipython side of things at 
all, I don't know why Baptiste took it that way (I didn't even mention ipython 
in my post).  My opinion was strictly based on the generic approach offered by 
gui_thread, and the potential benefit of doing things that way.

> 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.

One thing that I like about gui_thread is that it works in a generic manner. 
What happens with this patch if someone uses matplotlib but adds new widgets? 
Or if they embed a matplotlib window into something else? Are such usage cases 
covered automatically, or do they require special handling by third-party code?

There certainly are benefits to a matplotlib-based self-contained solution, 
and gui_thread comes with its own baggage, so I'll let you guys judge where 
the balance rests.

Cheers,

f