Re: looking ahead to 3.6

[Philip Nienhuis]

John Swensen wrote:
> 
> 
> On Feb 13, 2011, at 9:49 AM, Jordi Gutiérrez Hermoso wrote:
> 
>> 
>> Ok, more seriously, I'm really glad that you've looked favourably upon
>> a GUI. I am a little concerned that GTK+ won't be the best option,
> <snip>
> :
> Having said all this, I think there are a few options that seem
> reasonable:
> <snip>
> :
> (3) Pick a toolkit like Java (I am probably inviting a lot of flaming
> here) to implement the IDE in.  In some sense, this seems like the most
> reasonable solution to make sure we get all platforms.  The backend would
> be the same for all platforms (with the OpenGL stuff handled in the Octave
> C++ code) and the IDE would be supported on any platform that has a recent
> Java runtime.  There are toolkits on top of Java, like SWT from the
> Eclipse project, that provide better UI elements than default Java Swing.
> I'm not sure if there is a good terminal emulator widget for Java that
> works across all platforms (I'm assuming there is as Eclipse has one). 
> There would need to be a small Java<->C++ interface, probably similar in
> functionality to the octave_server class I use in OctaveDE.
> 

Not so much flaming but rather communicating some experience with Matlab's
GUI, which is based on Java (and perhaps more, I'm not sure). 
(Note: I've only got cursory experience with Java programming, so take the
next stanzas with a grain of salt pls)

ML has some 180 Java class libraries (.jar files; situation for r2007a)
included in its static javaclasspath (as an aside, almost filling up
completely the JVM memory slot for static stuff in r2007a, I got heaps of
PermGenSpace errors while experimenting).
When I was porting java-based io pkg (spreadsheet) scripts to ML, I needed
to swap one or two of the ML-supplied .jar files for newer versions. And
that did crash ML's GUI severely. It did look quite like native Octave
then.... (and like my old ML 5.3 Student Edition).

Apparently ML's GUI runs in the same JVM as user scripts and classes; or at
least, it is vulnerable for user interference. If Octave also goes for a
Java-based GUI, users may be bound to the Java class libraries the GUI is
based on, like in Matlab, to avoid instability. I think this is an
unacceptable limitation. 

I don't know how valid this issue may be for other GUI toolkits, yet IMO
user scripts & apps shouldn't be able to bring down (parts of) the
interpreter that runs them. It seems that at least Java brings along such
risks.

Philip
-- 
View this message in context: 
http://octave.1599824.n4.nabble.com/looking-ahead-to-3-6-tp3301974p3305758.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.