A few questions about gnuplot port (wxwidgets-devel & autoconf patches)

[Mojca Miklavec]

Dear Developers,

I asked for maintainership of gnuplot, but I need more input from the
more experienced developers to help me decide on some issues before
writing lots of different patches:

1.) Using wxwidgets-devel port (lowest priority, but simple question)

This is a yes/no question. I would like to link Gnuplot 4.6.0 against
wxwidgets-devel, since that would allow one to build 64-bit version of
gnuplot and also include some functionality that is not available in
2.8 (using mouse to move to the left and right of the graph).
wxwidgets 2.8 don't compile as 64-bit binaries and it might take
another year or more before wxwidgets 3.0 get released.
wxwidgets-devel are not released very often (maybe once every 4-6
months), so they are not really a fast moving target. It is just that
mac-related code has not been fully tested (also maybe not fully
implemented; there is no support for mouse gestures for example) and
other ports might not have been adapted for 2.9 yet.

So the question is: Is it allowed to make gnuplot depend on
wxwidgets-devel or not? Or maybe make two variants, one that depends
on wxwidgets and one that depends on wxwidgets-devel (and the two
conflicting with each other)?

2.) Including some Qt patches (low priority)

Since version 4.6.0 of gnuplot it is possible to use Qt terminal,
however there is a tiny stupid problem. Due to the way how qt terminal
has been implemented (some forking etc.), gnuplot would create two
windows in dock and one of them is completely useless, unresponsive,
ugly, ... so one of developers added the following code
    TransformProcessType(&psn, kProcessTransformToBackgroundApplication);
which hides that window from Dock.

This function works either with Cocoa or Carbon frameworks, but if one uses
    #include <Cocoa/Cocoa.h>
inside c++ code, this spoils everything, even after adding "-objC"
flag (without the flag, Cocoa.h is not interpreted properly and with
the flag, C++ is not interpreted as it should be; in either case the
program doesn't compile at all).

So there are two different solutions to the problem:
a) Using Carbon headers (I added a patch using that, but Ryan said
that this doesn't work for him on 10.6)
b) Splitting the part that uses Cocoa into a separate file.

The part (b) is somewhat "problematic" from the perspective of the
number of files that has to be modified. I have prepared a patch
against gnuplot 4.6.0:
    https://trac.macports.org/attachment/ticket/33596/gnuplot-qt-configuration.patch
(Changes in src/qtterminal/QtGnuplotWidget.cpp are not related and
have already been included upstream, all other changes are needed.)

However this won't work until somebody runs the "./prepare" script
which is only included in trunk, not in distributed gnuplot versions,
and it is probably against the policy of macports to run autotools
before ./configure anyway.

This is not a problem per se, I can run ./prepare script myself.
However I end up with *a lot* of changes in configuration scripts.
Basically all Makefile.in files and a lot more is changed
substantially just because I use a different version of autotools than
the main developer of gnuplot who prepares the release. I tried to use
git to do the following:
- run ./prepare myself
- apply patches
- run ./prepare again
- only exctract the changes done by the latest ./prepare
but when I compile the result, it ends up in a very weird way and
again fails to work.

So again some of my questions:
- Is it against MacPorts policy to include large diffs in Makefile.in
& configure script (where the majority of diff is related to a
different version of autotools)? An alternative is to find exactly the
right version of autotools installed and run the script on that
machine.
- Is anyone willing to help me test the patch? (I can try to prepare
the files more carefully in a single unified patch to simplify
testing, but I need to know at least if the previous part is
acceptable or not.)

3.) Default terminal (low priority)

Now that gnuplot has 4 usable terminals: aqua, x11, wxwidgets, qt,
some users might want to have different preferences and use, say, qt
as a default terminal. One can accomplish that by putting GNUTERM to
environment variable or to ~/.gnuplot file. The problem at my side is
that I have a lot of different gnuplot binaries all over the disk,
many of which don't have support for one or the other terminal. A
typical example is that I would like to make Qt my system default, but
that will break macports' octave which currently doesn't know about Qt
terminal in gnuplot.

I would like to modify the port in such a way that users would be able
to select default terminal with something like
    port install gnuplot +qt +wxwidgets +aqua +default_qt
Would that be acceptable? And if so, what should be the option name?

Thank you very much,
    Mojca