Re: dlgtest() no longer needs Octave package

[Philip Nienhuis]

Daniel J Sebald wrote:
> 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?

Yep, they just work. But not as smooth as in the latest java-1.2.9 pkg.

Perhaps you could download that, extract the *dlg.m files from the 
./inst subdir and swap them into place into the scripts/java subdir, 
just to try and see if they work more reliable.

> > > 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.

I have similar ideas, but IMO renaming the Java based dialog functions 
doesn't make much sense until there's a wrapper or so taking care of 
running the proper version based on Qt, OpenGL or whatever graphics 
toolkit is active.
BTW __java_inputdlg__.m etc. would make more sense.

Philip