From: Mojca M. <moj...@gm...> - 2014-12-08 09:55:29
|
On Mon, Dec 8, 2014 at 1:11 AM, sfeam wrote: > On Sunday, 07 December 2014 11:51:57 PM Mojca Miklavec wrote: > >> - gnuplot + wxWidgets 3.0 works fine for me on OS X; it has worked ok >> for a long time already, so saying that "wxt 3.0 doesn't work with >> gnuplot" is not entirely correct. > > That is good to hear. Thanks. > I don't recall hearing from you that things had started working with > wxt 3.0. I confirmed that it worked in http://sourceforge.net/p/gnuplot/patches/556/ plus a private thank you note to Adam and you (Tue, Sep 27, 2011). It wasn't the change from wxWidgets 2.9 to 3.0, but a change is gnuplot's source code that made it work. > The last Email I have was with regard to wxt 2.9, admittedly > from quite a while back. You said then: > > From: Mojca Miklavec <moj...@gm...> > To: sf...@us... > CC: gnu...@li... > Date: 01 Aug 2011 09:40 The relevant changes and fixes were probably committed with: 2011-10-09 Adam Strzelecki Work around compile issues on 64-bit OSX Lion (wx2.9 Cocoa) wxWidgets probably started working with: 2011-07-23 Adam Strzelecki On OSX, use single-threaded GUI and event loop which is when it made sense to raise the isssue about wxWidgets 2.9. >> There might be problems on linux, >> but it has worked fine on OS X long before anyone tested it on linux. >> (There might be special cases that fail to work, but in general it >> works.) > > Hmm. But wxt runs single-threaded on OSX, right? > So this may be another case where the single-threaded configuration > option is sufficient fix, except that on OSX this option is selected > automatically. Yes, that might be the case. (I also remember complaints about "persist" option breaking things.) >> The "sad" part would be gnuplot not being fixed to start working with >> wxWidgets 3.0 properly. (I don't have problems with 3.0 though.) > > Only if you accept that the problem is fixable on gnuplot's end. > That might be true, but if so no one has yet suggested what exactly > would need to be changed. I don't know that either. > The closest is a suspicion that it has > to do with threading. As I noted, some people have reported that > limiting gnuplot+wxt to a single thread makes things work better. > But for other people it doesn't. After that the list of suggestions > is empty. > >> Another very nice thing that would often help alleviate these kind of >> issues would be to start distributing gnuplot for Mac in a binary >> form. But that requires extra work. > > The Windows binaries on SourceForge are provided by volunteers. > If you have a line on a volunteer to provide Mac binaries... > Anyhow, isn't this exactly what fink, macports, and similar projects > exist for? Yes, but ... until MacPorts started to provide binary packages, installing gnuplot with Qt support meant that one had to compile the whole Qt from source. And as long as Lion supported compiling 32-bit wxWidgets 2.8 installing gnuplot with both Qt and wxWidgets meant that users had to *recompile* the whole Qt to include both 32-bit and 64-bit architectures (universal variant). At the moment Qt 5 cannot be installed together with Qt 4 and because many packages would fail to work with Qt 5, Qt 4 is still the default. Having a standalone app would be nice. Then whoever would package gnuplot could simply provide Qt 5, any version of wxt or whatever other libraries. And it would be easy to install for the users. The reason why this is more complicated than it should be is because gnuplot isn't working as a "standalone" application, but rather as a command-line tool. On windows there's a lot of code dedicated to that part: gnuplot on windows provides its own "terminal/console" (the part where user enters code, as opposed to providing just the plotting panel). On other OSes that part is missing. Implementing it in Qt should be feasible for someone familiar with Qt programming. I'm not skilled enough to figure out how to implement that part, but I would gladly volunteer to do the packaging of Gnuplot.app for Mac if such a tiny gui app existed. (At the moment the situation is somewhat acceptable. Fink, MacPorts, HomeBrew do their job, but having a binary download would nonetheless be nice.) Mojca |