Re: GUI doesn't appear when using ./run-octave

[Daniel J Sebald]

On 09/26/2012 10:31 PM, John W. Eaton wrote:
> On 26-Sep-2012, Daniel J Sebald wrote:
>
> | On 09/24/2012 05:16 AM, Daniel J Sebald wrote:
> |
> |>  I couldn't quite finish a patch that fixes a half dozen GUI bugs.
> |>  Hopefully within a day or so.
> |
> | I still need to make a couple small changes...close.
>
> Do you mean that you are working on a single jumbo patch that solves a
> half dozen unrelated bugs?  If so, then please split the patch into
> multiple patches with each one fixing a single problem.
>
> Thanks,
>
> jwe

It would be nice to do individual bug fixes, but what I'm doing is 
shuffling things around in a more slot/signal fashion.  The goal is to 
make solving all these bugs much easier because everything then falls 
under the one paradigm.  So, it's not like the bugs in the current code 
can be solved with simple conditional statements or something equally 
easy.  Instead there are problematic things like static variable 
"alreadyAsking" (which don't work under a multi-object paradigm, e.g., 
can't recognize multiple file changes on disk).

With the changes, I'm expecting it to become easier to develop fixes and 
solve bugs by making proper connections of signals and slots.

For example, I'm getting rid of constructs in which lower hierarchy 
objects are accessing higher hierarchy member functions.  That is, 
file_editor_tab should have little knowledge about file_editor or 
_main_window or whatever is connected on the other end of its signals; 
file_editor (the higher level object) should be setting up the 
connections in that regard.  dynamic_casts I'm removing...not the most 
egregious thing, but it moves a little too much outside the paradigm Qt 
has chosen.  Also, I'm moving the file open dialog inside the 
file_editor rather than file_editor_tab because that is where it 
naturally belongs.  With that change, it is simple to check whether the 
requested file is already open in the editor, otherwise some odd 
configuration is needed for a file_editor_tab to do such a thing.  I'm 
also getting rid of .exec() for all the dialog boxes (except the welcome 
wizard).  Freezing the GUI application waiting for user response isn't 
preferred.  That change consequently makes the find dialog NonModal, 
which is nicer behavior (i.e., can leave the find box open when editing).

So, there are a lot of bugs that naturally go away with the changes. 
It's not a lot of new code, just distributing it into slots and signals. 
 That's what is unique about GUI code.  One has to think of the code as 
being distributed, and the connections between the objects are analogous 
to some kind of state machine, or programming an FPGA or something. 
Example: "alreadyAsking" (i.e., don't keep creating dialog boxes if the 
file on disk keeps changing and the user hasn't answered yet).  The 
proper way to do that is

1) Remove the file name from the watcher
2) Create a QMessageBox to ask user if the file should be reloaded
3) Connect the message box "finished" signal to a slot
4) Indicate the message box should delete itself on completion (deleting 
that object in the slot often isn't doable because of a parent/child 
relationship, i.e., seg-fault when one of them is deleted)
5) Show the message box
6) Exit routine giving control back to the system so other things can 
continue to function in the GUIDE
--------
7) In the slot, respond accordingly to the user input, e.g., reload or 
do nothing
8) Put the file name back into the watcher

The line of hyphens above is meant to illustrate how processing is often 
split into two different locations.  One has to get into that frame of mind.

I'm in the final stages of testing here.  It won't have solved all bugs 
except those in the file editing.  (I can see several more related to 
shutting down, see below, but I'll leave those.  And I know the GUI has 
problems when coming back from some other application after a long 
while.)  Should make debugging and fixes easier though.

I've seen GUI developers for some other libraries that do all the 
signal/slot configurations behind the scenes and all one need do is fill 
in the code for the slots, or whatever.

Dan

PS: Couple error messages I often see at exit (at which point the app 
sometimes suspends):

QMainWindow::saveState(): 'objectName' not set for QToolBar 0x26ff7c0 'Main'

*** glibc detected *** 
/usr/local/src/octave/octave-gui_no_casts/build-gui-1/src/.libs/lt-octave: 
corrupted double-linked list: 0x0000000002827120 ***