[IPython-dev] Re: [SciPy-dev] Generic gui_thread + IPython: solution already exists!

[Prabhu Ramachandran]

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    >> I actually thought of using this approach earlier when I was
    >> fixing gui_thread, but thought IPython would need too many
    >> modifications for this to work.  However, it looks like
    >> Fernando has already done all the work for us.

    FP> Well, I think the real credit should go to John Hunter and
    FP> Antoon Pardon, the people who cracked the nut of the threading
    FP> code originally :)

Well, with all due respect to John, from Shell.py:

 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109, 

 by Brian McErlean and John Finlay.  
 Modified with corrections by Antoon Pardon.

So I think these guys should get the credit for the original idea.
The good thing with IPython is that you control the prompt.  So, this
approach is workable for you.  It won't work on vanilla Python or
IDLE.  That is more than good enough for me. :)

    FP> This is great news, obviously!

Yes!

    FP> This is very much what Eric and I originally discussed at
    FP> scipy'04, and what I thought might be possible to do.  While

Though I was right in the middle of that conversation, I did not
realize that you had taken the approach of pygtkconsole.py.  If only I
had known that, I would not have spent the time hacking gui_thread
recently.  Well, maybe that is a good thing because we have a
partially working gui_thread if someone needs it.

    FP> fumbling in the dark with my near-zero knowledge of threading,
    FP> in an attempt to get matplolib running, I finally thought that
    FP> perhaps this approach was just not viable, and that the full
    FP> complexity of gui_thread was indeed inevitable.  I basically
    FP> was not willing to believe that such a simple approach could
    FP> indeed substitute all the functionality of gui_thread, and
    FP> gave up in my ignorance.  I'm happy to see that my original
    FP> hunch was indeed right :)

:)

    FP> The leftover machinery for -wthread/-gthread which you see
    FP> there is all that's left of my efforts.  I'm glad I didn't
    FP> completely wipe that out.  Re-enabling it is trivial, and I
    FP> even had written the relevant manual parts for it, so this
    FP> would be an easy fix.

Yes.

    FP> I would be more than happy to put out a 0.6.5 release with
    FP> these fixes, since I think they would be a _major_ enhancement
    FP> to ipython.

Very good!

    FP> People have been asking for a long time for a way to use
    FP> wx/gtk interactively, and if this solution truly can
    FP> substitute gui_thread, I think it's a major win.  gui_thread
    FP> is complex and brittle, and the work of maintaing it is a
    FP> solid time sink with a developer bottleneck: basically only
    FP> you and Pearu (I think) understand that code enough to dare
    FP> stick your fingers in it.  IMO it would be great if we could
    FP> just get rid of it without loss of functionality.

No need to get rid of it.  The code can be used if someone needs it
but the recommended approach will be to use IPython.

    FP> I don't have the necessary expertise to properly test this out
    FP> for both wx/gtk, but I'd love to see these improvements go in,
    FP> so I hope you or someone else can finish them up.

I can send you a patch for the wxPython stuff and the preliminary work
for gtk.  I think John will have to fix the pyGTK code a little more
since he obviously knows a lot more than me about pyGTK.

    FP> Great work!

No, once again, I see that I'm just a blithering idiot.  I should have
seen this a long while ago.  My ignorance has gotten the better of me
again.  Better late than never though. ;-)

cheers,
prabhu