Re: color_radio_property implementation

[John W. Eaton]

On 25-Apr-2007, I wrote:

| On 25-Apr-2007, Michael Goffioul wrote:
| 
| | I wanted to keep the java code quite autonomous and usable outside
| | octave. So using the property database within octave was not really
| | a solution. Moreover, as java and C++ does not share the same memory
| | space, it would have been rather complicated and inefficient to have the
| | properties in C++/octave and have the java part constantly 
getting/converting
| | values from C++/octave to java.
| 
| OK.
| 
| I think it is unfortunate that we may have multiple implementations of
| the code to handle the graphics properties as I think that will lead to
| inconsistencies and some confusion for users.  Is there some way to
| avoid that?

OK, sorry for freaking out about the license.  As I understand it, the
Sun JRE is now free software.  Is all of it free software?  I don't
know much about Java, so are there features that we might want to have
(for example, GUI tools) that are not free?

Currently I see that we have several options for graphics:

  * Octave with its property database code (somewhat functional but
    increasingly clear that it is very incomplete) and various
    backends, possibly based on octplot, yapso, gnuplot, your code, or 
    some combination.  All but gnuplot use OpenGL.

  * Octave with your database code and the Java/OpenGL plotting
    libraries.

My original reason for wanting to have the database and rendering code
separate was to allow the possibility of separate backends.  But the
more I think about it, I'm not sure that is the right reason.  Writing
a graphics package that is reasonably compatible with Matlab looks
like a large job (there seem to be many tricks and complications) and
I don't think we have a large enough community that it makes sense for
us to split the development among N projects.

Also, from a the perspective of many Octave users, graphics is a core
feature, so I'm not sure it makes sense for Octave to have multiple
graphics backends that all behave in slightly different ways and that
all provide differing levels of compatibility.  It would be much
better to have only one that we all work on together.

jwe