On 2004-03-26, at 14.09, Hans-Bernhard Broeker wrote:
> On Fri, 26 Mar 2004, Per Persson wrote:
>> I'd say that the most important that aquaterm.trm no longer relies on
>> the AppKit framework which would cause a crash if a Quartz
>> window-server wasn't running for the logged in user (e.g. running
>> gnuplot remotely).
> Hmm... all put together, this feels like the aquaterm.trm is
> a rewrite from scratch, right?
> I guess we'll have to leave this decision up to you, then. The crucial
> issues to keep in mind would be: maturity of the new driver, and
> responsibility for possible bugs found in whatever driver we end up
> in the gnuplot source tree.
OK, then I'd say go for the new driver.
That way I could retire the old driver sooner than expected.
> As nobody on the gnuplot development team seems to have access to a
> box for testing, we'll have to rely on external experience for this.
> the moment, that external experience would appear to have to be you.
> So here's my proposal: you become a member of the gnuplot project team
> SourceForge.net, and take over responsibility for the aquaterm.trm
No problem, I'd have to do that anyhow.
> and all other MacOS X related issues.
This is the scary part...
I don't recall the exact release plan for gnuplot 4.0, but IIRC it is
more or less right away, no?
I'm really busy until mid April, but if someone whos is familiar with
gnuplot could bootstrap things and get the necessary changes(*) into
CVS, then I could find time to test them on OS X _before_ the next
From the end of April, I can commit more time to these things so, if
these reservations are OK with you, then I accept.
> E.g. something like this:
> in command.c:
> /* This whole chunk may better go to syscfg.h... */
> #ifdef __ObjC__ /* or whatever... */
> # include "gp_objc.h"
> #ifndef GP_OBJC_INIT_MEMPOOL
> # define GP_OBJC_INIT_MEMPOOL /* nothing */
> #ifndef GP_OBJC_FREE_MEMPOOL
> # define GP_OBJC_FREE_MEMPOOL /* nothing */
> /* body of function */
> gp_objc.h would then contain the #import statement, and #define the two
> macros to whatever they have to do on ObjC.
I like this. The __ObjC__ should probably be __HAVE_LIBAQUATERM__ since
this stuff is for the aquaterm driver, not OS X/ObjC in general.
I'll whip up the above solution, test it and come back with a patch.
* The necessary changes is to test for Mac OS X in configure (as is
and then check for libaquaterm
and only then set (if it is found)
LIBS="$LIBS -laquaterm -framework Foundation"
and set a #define to be used in command.c and term.h