Re: dlgtest() no longer needs Octave package

[Daniel J Sebald]

On 11/28/2012 01:41 PM, Philip Nienhuis wrote:
> Carnë Draug-2 wrote
> > On 28 November 2012 02:58, Daniel J Sebald<
>
> > daniel.sebald@
>
> > > wrote:
> > > Regarding some of the functions in the java package and directing to the
> > > broader list, are the names "errordlg", "helpdlg", etc. language
> > > standards?
> > > If not, I wonder if their names should include "java" in some way.  The
> > > reason I wonder is because if one launches Octave with the new GUI/IDE
> > > then
> > > it seems to me that "errordlg", etc. would be nicer as a Qt widget, not
> > > Java.  That way, it is the same look and feel and uses just one software
> > > exterior.
> > >
> > > I just tried creating some Java dialog boxes under the Octave IDE and it
> > > crashes on my system.  Should we start entering bugs for Java in the
> > > tracker, or wait a while?
>
> They work all right on my Linux box even when invoked from the GUI.
>
> But I see now that JWE has apparently transferred older versions of the
> dialog m-files into core Octave.
>
> IIRC I have updated them last June and July for minor style changes and to
> accept multiline input for the MESSAGE argument (i.e., cellstr arrays). It
> also says so on the Java package page f. version 1.2.9, function details, on
> the OF website.

I tried the inputdlg() in octave-cli and that works with multiple lines. 
 (It gives an arcane error about java.xyz something if the input format 
is not a cellstr.  That should be changed to a meaningful error 
statement conditioned in the script file.)

You're saying the versions of the java interactive elements now in 
Octave work on your system?  Or you have the latest version, and those work?


> > You are right, this things would look better as Qt widgets, and my
> > understanding is that these functions are going to be rewritten that
> > way. There's no reason for them to be limited to use java.
>
> True.
> But perhaps the Java-based dialog functions can still be present, yet
> shadowed by other (Qt? OpenGL?) versions. At least they do work now so these
> ML-compatible functions are now implemented.

Sure.  I meant that "errordlg" and "inputdlg" seem like they shouldn't 
be in a java subdirectory, but a more generic user interface directory. 
 Perhaps "javaerrordlg" and "javainputdlg" is what should be in the 
java directory.  If running without Qt IDE then inputdlg() would defer 
to javainputdlg(), etc.

Dan