[Octave-patch-tracker] [patch #7990] Add builtin Qt equivalents of UI dialogs, i.e., , qterrordlg, qtinputdlg, etc.

[Dan Sebald]

URL:
  <http://savannah.gnu.org/patch/?7990>

                 Summary: Add builtin Qt equivalents of UI dialogs, i.e.,,
qterrordlg, qtinputdlg, etc.
                 Project: GNU Octave
            Submitted by: sebald
            Submitted on: Mon 01 Apr 2013 10:58:12 PM GMT
                Category: None
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Attached is a patch that creates Qt dialogs similar to errordlg and so on. 
There is also an attached script file to illustrate and test all the different
input scenarios.

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
button, input box placement.  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.

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. 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. I haven't in any way altered code within the core to accommodate this.  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. I left notes, // 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.




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 01 Apr 2013 10:58:12 PM GMT  Name: octave-qtdialogs-2013apr01.patch 
Size: 54kB   By: sebald

<http://savannah.gnu.org/patch/download.php?file_id=27740>
-------------------------------------------------------
Date: Mon 01 Apr 2013 10:58:12 PM GMT  Name: qtdialogdem.m  Size: 3kB   By:
sebald

<http://savannah.gnu.org/patch/download.php?file_id=27741>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?7990>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/