Graphics Branch

[Shai Ayal]

Hi all,

It was decided that we wait with the new graphics back-end until 3.0
is out, and then work in a separate "graphics" branch. Well, 3.0 is
nearly here and I already have some code, but I think that maybe
starting a separate graphics branch will be counter-productive.

The problem is that I foresee 2 major sets of changes which will
happen in the graphics branch:
1. The addition of the rendering code -- this is largely independent
of the rest of octave and so it makes sense to develop in a separate
branch
2. A lot of additions and corrections to graphics.{h.in,cc}

This second set of changes will also be relevant to the gnuplot
backend. There will also probably be a lot of changes in
graphics.{cc,h.in} from the main branch, and so much time will have to
be spent on back-porting etc...

I propose to add the back-end to the main branch, but  in a way that
will not affect the gnuplot back-end and will be transparent to
cvs/release compilation -- it will only add other compile-time
dependencies to octave if explicitly asked for:

1. As I proposed earlier, each figure will have a "back-end" property
which will dictate which backend will render it. the default will be
"gnuplot". This property will be a string (as opposed to a
radio_property) so it will be open-ended, and future back-ends can be
easily accommodated. this change should not very hard to implement
2. A command line switch to the configure script will determine if
configure will look for graphics related libraries (opengl, fltk) and
compile the backend

This way, an unsuspecting user will be able to compile and work with
CVS octave without any problems -- no new compile-time dependencies,
no new plotting bugs/regressions, and the backend will benifit from
all work done in CVS head

Shai