octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

graphics future (was: Re: color_radio_property implementation)


From: John W. Eaton
Subject: graphics future (was: Re: color_radio_property implementation)
Date: Thu, 26 Apr 2007 02:55:41 -0400

On 25-Apr-2007, Quentin Spencer wrote:

| Shai Ayal wrote:
| 
| > While I agree that one back end is better, I do not like the idea of
| > octave depending on JAVA.
| 
| While we're busy complaining about Java's, let me add that the other 
| brand has implemented its GUI in Java, and I think it's slow and ugly 

I know very little about Java, and have never written a Java program.

Whatever we decide, I think it is important to have one implementation
for Octave that we all work together to improve rather than splitting
out efforts.

Also, I simply don't have the cycles to be the maintainer of the
graphics code.  I took my best shot at the property database code for
2.9.10.  If people think that is a reasonable design and someone would
like to maintain and extend it, then OK.  If not, then let's agree on
something else that is maintainable, extensible, and (perhaps most
importantly) compatible.

Also, at this point, I think gnuplot as a graphics rendering backend
is a dead end.  I just don't think that gnuplot works well as a
low-level plotter, and it is a lot of work to translate the property
data into gnuplot commands and make it all (sort of) work out in a
compatible way.  In addition, I don't see much hope for being able to
insert programmable GUI objects in a gnuplot graphics window and have
the kind of two-way communication with Octave that is necessary to
handle graphics and GUI features.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]