Windows defaults and the first example in the tutorial

Community matplotlib-users
1

I was thinking about the first example in the tutorial. On

    > windows, TkAgg is the default backend, at least for the
    > precompiled windows version. If Idle is run with -n, the
    > show() command must be omitted, or the window will not
    > render. Interactive2.py will try to render the window and
    > then hang, as will pycrust. I think the first thing a
    > newbie to matplotlib wants to do is open their favorite
    > shell interface and make sure they can reproduce the first
    > example in the tutorial.

Hi Darren,

This is a problem. It may be time to look into Pearu Peterson's
gui_thread which was developed for chaco but is easily decoupled from
scipy. It would be nice if the various backends played nicely with
the various IDEs. (One for the priorities list, Perry?)

In the meantime, I've added this warning to the win32 section of the
installing page

  Important: There are known conflicts with some of the backends with
  some python IDEs such as pycrust, idle. If you want to use
  matplotlib from an IDE, please consult the backends documentaion for
  compatibility information. You will have the greatest likelihood of
  success if you run the examples from the command shell or by double
  clicking on them, rather than from an IDE. If you are interactively
  generating plots, your best bet is TkAgg from the standard python
  shell.

JDH

2

    > I was thinking about the first example in the tutorial. On
    > windows, TkAgg is the default backend, at least for the
    > precompiled windows version. If Idle is run with -n, the
    > show() command must be omitted, or the window will not
    > render. Interactive2.py will try to render the window and
    > then hang, as will pycrust. I think the first thing a
    > newbie to matplotlib wants to do is open their favorite
    > shell interface and make sure they can reproduce the first
    > example in the tutorial.

Hi Darren,

This is a problem. It may be time to look into Pearu Peterson's
gui_thread which was developed for chaco but is easily decoupled from
scipy. It would be nice if the various backends played nicely with
the various IDEs. (One for the priorities list, Perry?)

Sure. But my recollection was that gui_thread needed a lot of work
(Eric Jones told me at least a month!), and it could well be that
one is needed for each gui (it does mapping of gui requests from
one thread to another or something like that so that a thread
running the mainloop allows the python interactive loop to run
separately. It would be nice if gui's played well with each other,
but I don't know if that is easy to do (or even workable for
all combinations). If someone knows how to do this sort of thing
that would be great, but we don't (neither the resources or expertise).
At the moment I take the position that it is simplest not to mix
gui's. The current rule of thumb should be that if you want to
use a shell that runs under a gui, you need the back end in matplotlib
to go with that gui.

I hope someone can make me a liar on that.

Perry

3

One more thought along this line. Perhaps it's possible for
matplotlib to inspect whether or not any of the supported gui's
has already been imported and make that the default. It seems
like a sensible rule to me. If none are found, then all the
other mechanisms apply.

Perry

4 
*
Sure. But my recollection was that gui_thread needed a lot of work
(Eric Jones told me at least a month!), and it could well be that
one is needed for each gui (it does mapping of gui requests from
one thread to another or something like that so that a thread
running the mainloop allows the python interactive loop to run
separately. It would be nice if gui's played well with each other,
but I don't know if that is easy to do (or even workable for
all combinations). If someone knows how to do this sort of thing
that would be great, but we don't (neither the resources or expertise).
At the moment I take the position that it is simplest not to mix
gui's. The current rule of thumb should be that if you want to
use a shell that runs under a gui, you need the back end in matplotlib
to go with that gui.
I hope someone can make me a liar on that.
Perry*

Some time back I experimented with gui_thread.

One fairly serious problem with gui_thread is that it is important which thread wxpython gets imported into.

Eric worked around this by printing a message once gui_thread had been imported which, interactively was a signal that it was ok to start using it. There is a README in the gui_thread package which has more details on this problem.

Now I was interested in gui_thread for two reasons: interactive plotting with chaco and creating python COM objects which fired up wxPython gui’s.

The latter is a bit challenging + the solution was to run the gui in a different thread. So I started off using gui_thread. I had to re-work the gui_thread code a bit, the trick was to do a bit less work when importing gui_thread so that I had better control of when wxpython was imported and hence could make sure it all happened in the right threads. I fed the fixes back to Eric, but I don’t think he wanted to change the semantics of gui_thread + as he seems to say it really needs a good re-think.

Meanwhile, Richard Emslie, who works with me took these ideas and has created a robust system for running this stuff in another thread.

Richard’s stuff works with a package called earthenware that we’re intending to release as open source. Earthenware contains a lot of our generic code that it really makes no sense for us to keep proprietary. Now one thing we are doing in earthenware is creating objects which separate the description of a GUI from its actual implementation. The description side is not toolkit specific. This helps a lot with the two thread problem, since the gui descriptions can be created in one thread and implemented in the other thread + you only need to import wx in the thread that does the implementation.

One other nice thing with this approach is you can build servers which create the gui descriptions, pickle up the objects and send them down a socket to a remote client which turns them into a GUI.

Currently, the only toolkit we have gui code for is wxpython + the set of ‘gui components’ we have are a bit limited + some need a little re-thinking, but the basic framework is proving powerful. We keep threatening to look at a pygtk version, which i suspect wouldn’t be huge amounts of work.

We’re planning on going to Europython in June + would be happy to meet up with anyone interested in this stuff.

The earthenware site is here: http://www.earthenware-services.org/earthenwarewiki/.

As yet we haven’t put the code I’m describing above, we really need to pull our fingers out and get the code out there – will try and get some sort of tarball out there very soon. For now all you will find is a python package which writes gnumeric spreadsheets.

John