John Hunter wrote:
>>>>>>"Baptiste" == Baptiste Carvello <baptiste13@...> 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.