Re: Mac OS X driver. [Was: Please check new TBOOLEAN...]

[Per P. <per...@ma...>]

On 2004-03-26, at 12.59, Hans-Bernhard Broeker wrote:

> On Fri, 26 Mar 2004, Per Persson wrote:
>
>> It is currently in alpha testing and I discussed the subject with Lars
>> Hecking and it was decided to wait until after the 4.0 release. 
>> However,
>> the new driver has matured rapidly and is much cleaner than the old
>> driver and supports more gnuplot features.
>
> It's hard to make a decision on such imprecise information.  Maybe you
> should post the current state of that driver somewhere, including an
> explanation why you think it's better, what new features it supports, 
> and
> so on.  Otherwise, we'll leave just stick with Lars' decision to 
> postpone
> it.

Of course, these are the major changes that affect the gnuplot driver:

AquaTerm::ReleaseNotes

AquaTerm 1.0a1
   Breaking backwards compatibility.
   Complete rewrite with better possibilities for future optimization.
   Supports mouse and key events (events in general actually). (#538268, 
#586499)
   Respects window size when updating. (#650938)
   Make window front when updated. (#651911)
   Added debug menu including "Refresh view", a test view and feedback 
options.

aquaterm.trm::ReleaseNotes

AquaTerm 1.0a2
     Process a lot more options. Currently supported options are:
     <n> title "theTitle" size <x> <y> fname "fontface" fsize <fontsize>
     Points and boxfill Implemented.
     Autoreleasepools should be handled in command() in 
gnuplot/src/command.c,
     leave a last line of defense in the driver.

AquaTerm 1.0a1
     Moved all common code into libaquaterm.dylib, all adapters link 
with this.
     Complete rewrite of common code, no reliance on AppKit (#605549)
     Increased resolution (#783895)
--------------

There are more details at the sourceforge site:
http://aquaterm.sourceforge.net/
http://cvs.sourceforge.net/viewcvs.py/aquaterm/adapters/gnuplot/

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).

My personal favourite is that all core functionality lives in a lib 
rather than the driver(s).  Drivers are now simple enough that most 
bugs should occur somewhere else and can be fixed without recompiling 
clients such gnuplot.

The new set of options might also make some users happy.

>
>> I'd also like to patch command.c to fix a problem with the
>> semi-automatic garbage collection in Objective-C that could lead to
>> excessive memory use during long running sessions.
>
> ObjC code in the middle of the native C stuff might be bad news.  At
> minimum, I'ld like to see this isolate to a separate source file, which
> a plain C compiler won't even look at.

OK

>
>> What it does is to set up and tear down an "object pool"  for every
>> loop through the event cycle. Placing it here is based on the
>> assumption that all calls to the driver is guaranteed to be made
>> through this single function.
>
> "Through" this function: almost certainly.  But I would think this 
> could
> more sensibly be put into your term->graphics() and term->text(). Those
> are called once per plot generated, which really should be sufficient 
> for
> your needs.

Yeah, I used to have them there, but I didn't feel entirely comfortable 
with not creating/destroying in the same scope.

> It'd also have the benefit of placing these Chunks in a place
> that already is out of sight of non-Objective-C compilations.

Hmm, the ObjC compilation is done by adding -ObjC to _all_ 
compilations, so in a sense placing the stuff in command.c with #ifdefs 
places the code on the same visibility level as aquaterm.trm in term.h.

Anyhow, you are probably right that we should keep C and ObjC separate.

/Per