Re: patch to configure.in & aclocal.m4 for graphics libraries

[David Bateman]

Michael Goffioul wrote:
> On 9/15/07, Shai Ayal <address@hidden> wrote:
>>> Does this mean that at some point, octplot (or a derived product)
>>> will become the de-facto standard graphic backend of octave?
>> The plan is to include a renderer in the octave distribution. It will
>> be based on the octplot rendering code with modifications to handle
>> 3D. All the object tree management will be done by the octave
>> object/property code which is already in place and has no connection
>> with octplot.
>> Use of different renderers could be facilitated by a "renderer"
>> property for each figure which would determine which renderer would
>> render the figure. This way you could have several figures each
>> rendered by a different renderer.
> 
> If octave comes with an integrated graphics backend with decent
> features, I don't really see the point of continuing developing JHandles,
> as nobody will use it anyway (why would you install and use a 3rd
> party backend, if you have already one that works). Having choice
> is not always what the user wants: he just wants something that
> works. And as John pointed out, it's a spreading of resources.
> I'll then re-think my commitment to JHandles.
> 
> Michael.
> 

Shai,

When and by who was such a decision made? Yes I've seen comments that
gnuplot just doesn't cut it and should go, but what exactly it'll be
replaced with I've seen no final decision.

That being said, I'd personally love to see as much as possible of the
handle system itself in octave core sooner rather than later, Frankly
what is there now is incomplete at best. Michael has been working on a
number of the missing features (barseries, areaseries, etc) in jhandles
and it would be if as much as possible of that also when into the core,
Equally, I'd love to see some of the specialized plots (quiver, pie etc)
that are part of octplot included, though till gnuplot is dumped that
probably means writing backends for gnuplot as well.

The final decision on what renderer to include in the core should be
made after 3.0..

D.

PS: I also agree with Michael that when a compatible renderer is in the
core the others will be a dead-end