gnuplot: question about wxWidgets(-devel)& Universal variants

[Jonathan Stickel]

On 3/13/12 08:57 , Mojca Miklavec wrote:
> On Tue, Mar 13, 2012 at 15:24, Jonathan Stickel wrote:
>>
>> wxWidgets and 64-bit has been a real PITA for some time now. The
>> development series 2.9 has promise, but there are some problems.
>
> I would have asked "what kind of problems", but I don't want to open a
> can of worms ;)

I have found that it is not compatible with Mayavi (a python 
visualization program), and I suspect the same for other projects that 
use wxwidgets.

>
> At least it works for me for using a Gnuplot terminal. The old version
> (2.8) also works of course, but only for 32-bit applications and it
> lacks two nice features which is a bit painful.
>

If it works for you, great!

>>   If you
>> really need wxWidgets, I suggest using the X11/gtk backend.  See this old
>> ticket for a full explanation:
>
> I have no idea how to use X11/gtk backend, and since wxWidgets-devel
> also work (with Cocoa interface), I see no reason for including yet
> another alien into the game. But if that would simplify macports
> packaging and if somebody can show me how to do it, I have nothing
> against a working solution. I don't particularly like X11 thouh and
> there is already an X11 terminal available (with slightly less
> features), but if that's what it takes ...
>

Everything needed for the variant should be in the "wxwidgets-python" 
portfile.  A simple copy of the relevant lines to the wxwidgets portfile 
should work OK.  Some bug-squashing might be needed.  But if 
wxwidgets-2.9 works for gnuplot, that does seem like a better solution 
than X11/gtk.

>> http://trac.macports.org/ticket/24350
>
> I'm not sure that I understand all of what is written here.
>
>> The variant for the 64-bit capable X11/gtk backend is available in the
>> wxwidgets-python port.  This could be translated to the regular wxwidgets
>> port if someone is interested.  I have stopped using wxwidgets due to these
>> problems and am now using qt4.
>
> I would never develop a wxWidgets application myself, and even the
> author of wxWidgets code for gnuplot says that he is no longer
> interested in further maintainance (and that he would have written Qt
> code back then if he knew what he knows now). But since the code is
> there and application works now, it would be nice to support it as
> long as supporting is not too painful. The Portfile that I wrote
> (https://trac.macports.org/ticket/33596) seems to work, its only
> drawback is dependency on wxWidgets-devel and I'm not sure how that
> works on older macs.
>
> Gnuplot now also supports Qt terminal (which is not really polished
> out yet, at least not for the mac; printing semi-crashes,
> configuration is suboptimal and doesn't work out of the box), so Qt
> terminal is definitely an alternative. It would help if some
> knowledgable developer would fix a few mac-specific problems in
> gnuplot source code though (I can describe problems, but don't know
> how to solve them properly).
>
> I wouldn't have used MacPorts' gnuplot at all, but I don't know any
> other way if I want to use Octave. And AquaTerm is causing me serious
> problems (= it doesn't work at all), so I need at least one working
> terminal that's different from AquaTerm and both Qt and wxWidgets are
> good candidates that finally happen to work on mac in gnuplot 4.6.
>

I am facing similar problems with wx vs qt backends for matplotlib and 
mayavi in python.  wx used to be the standard backend, but is being 
phased out (I think partly because of this painful transition from 2.8 
to 2.9).  Qt4 is the new preferred backend, but not all features work 
correctly.  This has been an issue for over 2 years now.  Hopefully 
things will get better over time.  I have decided to got the Qt4 route 
and am dealing with the few issues.

Jonathan