Re: [matplotlib-devel] Re:

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

>>>>> "Kirill" == Kirill Lapshin <ki...@la...> writes:

    Kirill> Oh, I see. That explains it. I tried it from PyCrust and
    Kirill> it does work much better, though still there are some
    Kirill> rough edges. Interactive mode works, which is the most
    Kirill> important one for me, but non-interactive does not return
    Kirill> back to python prompt after show() command, also cursor
    Kirill> turns into hourglasses when it is over plot window. Looks
    Kirill> like there are still some problems with message loop.

This isn't too surprising.  One thing show does in backend_wx is

    if not matplotlib.is_interactive():
        wxapp.MainLoop()

Ie, if you issue show and you are not in interactive mode, you'll have
dualing wx mainloops.  Moral of the story - make sure your IDE toolkit
matches your backend toolkit and set interactive : True in
matplotlibrc if you want to work interactively.  All other
combinations are expected to fail.

    >> However, I'm quite concerned that launching from the Windows
    >> console causes problems. It should work correctly, provided
    >> that python is on the path and WxPython is installed correctly
    >> in site-lib.

    Kirill> Yes, python is on the path, wxPython installed correctly
    Kirill> in site-packages. So what is the deal with "recommended
    Kirill> way" of running from console? pythonw will detach from
    Kirill> console, but what -dWX do? It is passed as an argument to
    Kirill> script, so looks like it is responsibility of the script
    Kirill> to use it. Does that mean that WX backend can not be used
    Kirill> from regular console python shell? That would be quite
    Kirill> unfortunate, because for example IPython only runs
    Kirill> interactively on console.

No, in general, the only backend that can be used from a regular
console python shell is tkagg.  To use GTK* interactively, you need to
use one of the GTK shells described on
http://matplotlib.sourceforge.net/interactive.html and to use WX
interactively you need pycrust or another wxpython shell.  This is a
threading issue.  Unfortunately, getting the standard python shell to
play nicely with GUI threading is not trivial.  The best attempt thus
far is scipy's gui_thread which according to some reports is still
immature and is definitely not generic across GUI toolkits.

    Kirill> I am hoping someone familiar with TkAgg backend will step
    Kirill> out and help with Tk problems.

See Todd's suggestions on the user list.  I think you should have no
trouble with ipython or the standard python shell with the following
settings in matplotlibrc

backend      : TkAgg  
interactive  : True
tk.window_focus   : True

This last setting doesn't play nice with IDLE if I recall correctly so
use with caution.  If you encounter troubles with this combination
please let us know.

    Kirill> BTW, since decision which backend to use depends quite a
    Kirill> lot on program you are running matplotlib from, would it
    Kirill> be possible to autodetect host program and choose
    Kirill> appropriate backend?

We've talked about it before.  It shouldn't bee too hard to inspect
sys.modules and figure this out.  I'm not sure how it should be
handled vis-a-vis matplotlibrc.  Perhaps we a new default

backend      : Auto

which 

  1) Inspects sys.modules to see if a GUI toolkit is loaded and uses
     it if so

  2) Otherwise tries to load systematically load gui toolkits in a
     platform dependent manner (wxpython or tk for enthought/win32,
     gtk for linux, etc) and with success sets the backend

  3) falls back on Agg or a warning if all three fail

Of course if the user explicitly sets the backend this pathway would
be ignored.

I'm on the fence as to whether this is a good idea.  If we automate
too much it becomes more difficult to figure out what is going on in
case of problems, and it prevents users from figuring out how to
customize and control matplotlib.  On the other hand, if people throw
up their hands in disgust with repeated failures and complexities,
that is a bad thing.

JDH