[Octave-bug-tracker] [bug #37359] Gui frozen at start

[Dan Sebald]

Follow-up Comment #3, bug #37359 (project octave):

You'll have to take this description with a grain of salt because these gui
things for which flow goes from the application back to the GUI system and
back to the application can always be tricky, but I think the above fix is
good.  It doesn't solve everything (see below), but I don't want to do too
much at once.  At least it clears the way to work on other related items.

First, I made a slight change to the way in which the settings change
notification is done.  In the hunk of code (main_window::read_settings) I
posted to maintainers list on 09/16/2012 01:44 PM is the instruction:

emit settings_changed ();

Notice a couple things.  One, "read_settings" is called ultimately from the
main_window constructor.  Two, the slots for the signal (i.e., objects to be
notified if the signal occurs) are defined in the main_window constructor just
prior to the call to read_settings:

  connect (this,                        SIGNAL (settings_changed ()),
           _file_editor,                SLOT   (notice_settings ()));
  connect (this,                        SIGNAL (settings_changed ()),
           _files_dock_widget,          SLOT   (notice_settings ()));
  connect (this,                        SIGNAL (settings_changed ()),
           this,                        SLOT   (notice_settings ()));

and contain objects which include the file editor, dock widget and the main
window itself--all objects having association with the main window (i.e,
"this").

My way of thinking is that there shouldn't be any signals relayed to an object
while it is in the stage of being constructed.  All internal memory/variable
definitions might not be complete yet.  Whether this ultimately was one of
several launch problems, I'm not sure.  But it is just good practice to not
let the GUI core mess with things that aren't yet fully constructed. 
Otherwise there could be a race condition, which is what I'm seeing when there
are settings for the file_editor within the settings file.  Sometimes the
windows would appear, sometimes not.  Again, grain of salt, and I haven't the
desire to pinpoint the exact cause and effect.

So, I made the change to move the update of the settings to after the
main_window construction is complete.  It's an easy change, and requires
making read_settings and write_settings public, but I see no problem with
making those public.

...

After that change, I then began getting more descriptive error messages in the
STDERR stream, which uncovered a segmentation fault in the file_editor.

I was getting an error upon the

  QsciLexer *lexer =  _edit_area->lexer ();
  delete lexer;

in file_editor_tab::update_lexer ().  (Lexer creation is done twice at start
up, but I'm not sure why.)  It was only the m-file editors that were creating
problems.  Cut to the chase, I think the pointer for the created QsciAPI,
i.e.,

      QsciAPIs *lexer_api = new QsciAPIs (lexer);

was being discarded when it should have been kept for deleting later on. 
Because the QsciAPIs wasn't being deleted it was hanging around after the
lexer_octave_gui had been deleted.  Hence, it was attached to something that
didn't exist anymore. 

So, I moved that code for building the QsciAPIs inside the lexer_octave_gui
constructor, and the destructor now deletes the QsciAPIs.  That seems to have
solved the main problem of launch.

...

Before figuring out the previous bug, I noticed that
file_editor_tab::save_file was using

   _file_name = saveFileName;

That is actually a bug because the lexer isn't being updated by just setting
the file name.  For example, if a file called foo.m (having Octave lexer) was
saved as foo.txt the Octave lexer remained, and text was highlighted as though
the file were still foo.m.  This is much cleaner than before and behaves just
as expected from an editor.

...

With all that, the problems at launch are solved, but not the following:

1) File editor lexers being created, then destroyed, then created again when
only creating once is necessary.

2) All kinds of error messages and system hanging upon exit.

3) The command window still doesn't function just right.  Often commands won't
appear until after moving the position cursor around.  It starts acting
strange after a large printout is put into the pager.

This patch isn't meant to address everything except the immediate problems. 
So, if there are some quirky behaviors, take notice and enter them into the
bug tracker separately.



(file #26569)
    _______________________________________________________

Additional Item Attachment:

File name: octave-gui_launch_cleanup-2012sep17.patch Size:8 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37359>

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