Am Dienstag, 10. August 2010 23:20:41 schrieb Michael Goffioul: > There has been a lot of confusion in this thread. The GPL violation I > mentioned was not against jhandles, but against the Windows binary > package I used to provide. Those MSVC-compiled binaries contained a > working version of jhandles. When I mention the GPL issue, I was > specifically referring to the Windows binaries. > > Now, concerning jhandles itself, it has been written whene there was > no graphics code in octave. It implemented its own modules (property > system, rendering, windowing) entirely in java. A large part of this > is now natively available in octave (for instance the OpenGL rendering > in octave is actually a rewrite of jhandles rendering in C++), making > their jhandles equivalent obsolete. Jhandles has grown unmaintained, > because I spent my time (re)implementing the graphics code in octave > rather than keeping it up to date. So the bottom line is: current > jhandles implementation is not suited for current octave code. > > I think there's still room for a java-based backend, but it should be > rewritten as a thin wrapper on top of octave, making use of octave > tools (like the OpenGL renderer). I wrote some experimental code a > long time ago, using that idea. I could pass it on if anybody is > interested. While keeping the current implementation is theoretically > possible, it doesn't really make sense as a large part is redundant > with octave's code. > > Concerning printing jhandles plot, I think your best chance at the > moment would be to make the figure background white, then use your > favorite screenshot tool to take a snapshot of the figure content. > It's better than nothing... Jhandles used to be able to print figures > to png, but I'm not sure it's still working. > > Michael. > Thank you for clarifying the status of jhandles. I understand that the focus is now on fltk (which I use very much). My regret is that there are still some things in jhandles which I miss in fltk (the gui functions and the lighting capabilities). My knowledge about C++ is as old as my windows programming skills, but the latter ones are not needed for fltk. So I understand if I want to help improving the graphics capabilities of octave it seems to be better if I make myself familiar with the fltk backend code (and renew my rusty C++ knowledge) and try to add functionality there? Is that correct? Then I will check the next days where I see a chance to help improving the fltk backend by working on missing functionality.
- mh ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
