Re: [OctDev] Java/OpenGL-based graphics package for octave

[David Bateman]

Michael Goffioul wrote:
> On 4/23/07, David Bateman <address@hidden> wrote:
>> Just a comment on the src/Makefile, which contains
>>
>> <quote>
>> CLASSPATH = jogl.jar:/usr/local/octave-vc8-debug/forge/java/octave.jar
>>
>> all: oplot-gl.jar
>>
>> oplot-gl.jar:
>>        javac -cp $(CLASSPATH) -source 1.2 -target 1.2
>> org/octave/graphics/*.java
>>        jar cf oplot-gl.jar org/octave/graphics/*.class
>> </quote>
>>
>> You can't hard-code the CLASSPATH in that manner. Maybe you need a
>> configure script to probe what this value should be. Furthermore I'd
>> suggest modifying the all target to be
>
> Don't pay too much attention to the Makefile. I wrote it quickly to
> provide
> something that's compatible with pkg.m. But in the end, I also include
> the
> compiled jar file into the package archive (as Java-code is
> cross-platform)
> such that a user does not need JDK (which is usually the case).
> Hardcoding is not a final solution, but I didn't want to spend time
> now on
> writing configure test for finding JOGL and other java-related stuff
> (I also
> might relocate the octave.jar archive from the java interface package).
>
> However, putting the JAR files into the bin directory is a nice idea.
> That
> should ease the loading of JVM.
>
>> I also don't think the high level plotting functions such as
>> stem, surf, image, legend, etc should be touched (though surf isn't in
>> octave yet), but rather only the code that is called after a drawnow, to
>> have a simple separation between the graphics front-end and back-end.
>> This might mean that there are some frontend changes you need, but the
>> front-end code definitely shouldn't have java specific code in it. This
>> goes equally for patch and light which should be in the front-end with
>> appropriate objects in
>> src/graphics.cc and then only rendered into java in the backend.
>
> I did it when it was possible (I overloaded some of the __go__*
> functions). But sometimes it was not, because the function did not
> exist (patch, light, surf) or it was too different from the Matlab-way of
> doing (stem, legend).
Yes, but you even modify the line function...

>
> For instance, a legend in Matlab is a complete independent axes object
> which is a regular child of the figure (you can even set its view to
> 3D mode),
> while in octave it's a set of properties spread between the axes
> object and
> the line objects (Matlab does not jave "key", "keypos" or "keylabel"
> properties).
Ultimately the best way would be to make legend compatible with the
matlab way of doing things in the frontend, so you wouldn't need to
modify it.

>
> I also agree that there should be a clear separation between the
> front-end
> and the back-end (the front-end should be "java-free"). However this also
> means that the front-end should be flexible enough for various types of
> back-end and keep the auto-computed things at minimum. For instance,
> in stem, I don't want the front-end to compute the xdata/ydata values and
> create the baseline, I'll do it myself (I insert NaN's between stem
> lines and
> the baseline is a special object). But all this will become clearer
> when other
> backends will pops up.
Again is there a way to modify stem that gets the front-, back-end
separation right?

>
>> In any case Michael, this is great and I even if it is only Windows,
>> intgerate it with your MSVC build and it might well become the most used
>> octave graphics backend of all..
>
> It's far from finished. But I wanted to give other the opportunity to
> test it
> and get some comments. Also, it's better to work on the front-end in
> cooperation with octave development (that's why I didn't spend time on
> the front-end functions and just use quick-and-dirty dedicated functions
> for testing purpose; I knew it would need to be rewritten for better
> integration
> with octave).
I suppose, I was worrying more about the front-end than the backend
whereas your purpose is to get the backend running and then worry about
the front-end. Hey, it'll work out in the end either way..

Cheers
David



>
> Michael.
>


-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary