Qt versions of dialog functions

[Daniel J Sebald]

I've created a patch for Qt versions of the dialog functions here:

https://savannah.gnu.org/patch/index.php?7990

I've created the equivalent to the script files in the scripts/java 
subdirectory, using the same documentation from those files for the time 
being.  I've tried to make the behavior the same in terms of the order 
of buttons, input box placement, <esc> key, and close button.  The names 
simply have a "qt" prefix:

qterrordlg
qthelpdlg
qtwarndlg
qtmsgbox
qtquestdlg
qtlistdlg
qtinputdlg

I didn't recreate the dlgtest.m routine because I feel that function 
should remain as a script file so that it gives examples of how to use 
the code for the user.  My thinking is to incorporate Qt into dlgtest.m 
is to uses "eval" and prefix "qt" in the appropriate places based on 
conditions.  It should be very easy given the "isguirunning()" command. 
 Also, I didn't want to start including script files related to GUI 
just yet. This is sort of the first instance of GUI-related builtins, so 
one step at a time.

I did, however, create a nice set of test scripts attached to the patch 
report.  We could make that a script file, but I didn't want to start 
adding those just yet either.  (See 4 below.)

There isn't as much code as the amount of ASCII text would lead one to 
believe.  In retrospect it all is very straightforward.  Took a bit of 
creative thinking to arrive at it though.  That's just the way Qt is. 
If it feels like things are being forced too much, there is probably a 
better way to do it.  So one has to just take time to think.

Some comments:

1. The documentation is the same as that for the Java versions, with 
slight adjustment.  Those files are listed Copyright 2010 Martin 
Hepperle, so I'm not sure what the copyright info should be for the new 
qt equivalents.  Code is all new, but copyright often extends generally 
to written material.

2. The communication uses a mutex/wait-condition to suspend the Octave 
thread while the user responds.  This is the way the Java dialog boxes 
operate.  The user's response will wake up the Octave thread.  The 
obvious result is that the command-line window is frozen even though the 
rest of the GUI is accessible (not bad).

3. The ramification of 2 is the limited nature of the dialog boxes. 
First step, I suppose.  But, I don't think Octave/GUI interaction is 
currently setup well enough to run nonmodal dialog windows.

4. John/Rik, I'd like you to look things over and see if there is 
anything you'd like changed such as the way files are built, 
directories, syntax, inclusions, etc.  As I pointed out previously, my 
goal was to keep any GUI related items in the "libgui" subdirectory. 
However, the "make" process is currently set up to have builtins under 
the "libinterp" subdirectory.

5. John, peruse the way in which the QMutex/QWaitCondition work, and the 
way in which signals/slots are set up.  Hopefully this is a good example 
of Qt's intended model.  Notice that I haven't in any way altered code 
within the core to accommodate this.  Also, not all the code in 
dialog.cc is run as part of the Octave thread.  Some of it is run as 
part of the GUI thread.

6. Whenever I could, I set up the widget code suitable for non-modal 
behavior...even though that could be down the road and there might 
likely be a different paradigm.  In other words, these dialogs would be 
a good start for something more sophisticated.

7. John, there are number of cases where the command line inputs are 
supposed to be integer.  Is there an existing way of testing this?  If 
so, could you please make some followup patches or point me to the right 
hunk of software?  I didn't write such a test because I was thinking 
maybe just converting the user input (if it tests out to be numeric) to 
an index type would inherently check that the vector is integer.  I left 
a note (// SHOULD CHECK IS INTEGER) in the code.  I want to reproduce 
the following behavior in some simple way:

octave:5> x = [1:5]; x(2.5)
error: subscript indices must be either positive integers or logicals

I know that gripe_invalid_index() generates that message, but I'm 
wondering if there is some single line instruction that will do the test.

8. I left out the icon for the qtlistdlg() and qtinputdlg() routines. 
Having a question mark next to the list doesn't necessarily make sense, 
nor does it look that good and it takes up a lot of space.  I like the 
qtlistdlg without the icon.  I can add it easily enough.  I'm pretty 
certain no one will want a question mark icon.

9. The qtquestdlg() has the button order button1 | button2 | button3 on 
Gnome.  However, I've had to use a transmutation of the button roles to 
do this.  Different platforms may have different button orders, so 
things might be backward on other systems.  I've tried being tricky by 
assigning all the buttons the same role, but Qt gets confused by that. I 
could easily write a custom dialog that maintains the same button order 
on all systems, but I'd rather give the QMessageBox a try first. Qt is 
trying to think more in terms of a button's role so that it can adapt to 
all the various UI's out there.  Maybe that is what the questdlg() 
should be doing anyway.  Let's see how that pans out.

10. I used the "isguirunning ()" function to prevent the qt dialogs from 
signaling and then waiting for a signal that will never arrive.  Might 
we want to make "isguirunning ()" more informative by specifying what 
gui is running?  E.g., "qt" or "qt-4.0", or some other toolkit.

11. There is a FIXME in dialog.h, but that one isn't my fault.

Well, run the dialogs through their paces and if anyone finds any bugs, 
create a bug report and point me to it while this is fresh in my mind.

Dan