Hi Alan
I've made a bit of progress on add ing threading to the wxWidgets driver - there is still some work to do however.
Currently I've got to a point where I can start a new thread, begin the event loop and create frames. However there is some Windows specific code in there. The reason is that the cross platform wxThread cannot be used until after we call wxInitialize - however the event loop must be started in the same thread that we use to call wxInitialize. You can see the issue.
I'm sure there are equivalent threading functions on the various operating systems we might want to support. I can find out how to do this on Linux, but I don't have access to a mac. I'm not sure what other OSs we should be supporting - but it could be a long list.
The possible saviour here is that C++11 includes std::thread which would give support to any compliant compiler. Could CMake check for apropriate compliance at build time? Perhaps including code for C++11 std::threads with fallbacks to Windows and Linux (and OSX if someone can do it) specific code would be the best solution.

From: Alan W. Irwin <irwin@beluga.phys.uvic.ca>
To: phil rosenberg <philip_rosenberg@yahoo.com>
Cc: PLplot development list <Plplot-devel@lists.sourceforge.net>; Andrew Ross <andrewross@users.sourceforge.net>
Sent: Tuesday, 26 February 2013, 23:41
Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window

On 2013-02-26 14:19-0800 phil rosenberg wrote:

> Hi Alan

> Okay, well to impliment that behaviour (CR or right click causes
page advance) with wxWidgets is going to
require us to go down the multithreading route - quickly glancing at
the Qt code I can see mutexes mentioned right up near the top of the
source so I guess that's what Qt does too.

Hi Phil:

Whatever you decide to do is fine with me so long as you preserve
present behaviour (the page advance with CR or right click continues,
the present pause behaviour continues (see below), and the
test_c_wxwidgets comprehensive test of the wxwidgets device continues
to pass) while solving the issues shown by test.c.

> Again just to make sure I get this behaviour correct, in the current
wxWidgets driver program flow stops with the wxWidgets window when
pleop() is called and only returns when the plot page is advanced with
a right click or enter press. Is this the correct behaviour?

Yes.  After all, the user normally wants a chance to look at the page
being displayed rather than skipping through all the pages.

> I've spotted the plspause() function in the documentation, when set
to false should the driver return from a pleop() call immediately and
just skip through all the pages? That seems to be the implication.

Yes. For that special case (also with the -np command line option
which ends up calling plspause(0) in plargs.c) the pages just should
skip by with no pauses. Note, that the test_c_qtwidgets actually uses
the -np command-line option by design so that whoever runs that test
doesn't have to go crazy clicking on all the windows to get through
the plots. But normally users do not use the -np command-line option so that the user can study the results for each plotted page.

Note my run-time tests show that the page pause logic is already
correctly implemented for wxwidgets (see also the pls->nopause logic
in drivers/wxwidgets.cpp) so your changes should insure that logic is

Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).

Linux-powered Science