Tue 18 Sep 2012 01:32:13 AM UTC, comment #3:
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)
|