octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #53835] GUI Settings: Variables used by handle


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53835] GUI Settings: Variables used by handle_settings (e.g., m_custom_style, et al.) are not initialized
Date: Fri, 4 May 2018 12:07:51 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

URL:
  <http://savannah.gnu.org/bugs/?53835>

                 Summary: GUI Settings: Variables used by handle_settings
(e.g., m_custom_style, et al.) are not initialized
                 Project: GNU Octave
            Submitted by: sebald
            Submitted on: Fri 04 May 2018 04:07:49 PM UTC
                Category: GUI
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Missed Error or Warning
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: Any

    _______________________________________________________

Details:

As part of fix for Bug #53276 I originally made a change that basically
reversed the order in which the GUI layout and GUI settings are done at
startup.  That is, I made the change:


@@ -1203,34 +1188,35 @@ namespace octave
   }
 
   void main_window::read_settings (void)
   {
     QSettings *settings = resource_manager::get_settings ();
 
     if (! settings)
       {
         qDebug ("Error: QSettings pointer from resource manager is NULL.");
         return;
       }
 
+    emit settings_changed (settings);
+
     set_window_layout (settings);
 
     // restore the list of the last directories
     QStringList curr_dirs
       = settings->value ("MainWindow/current_directory_list").toStringList
();
     for (int i=0; i < curr_dirs.size (); i++)
       {
         m_current_directory_combo_box->addItem (curr_dirs.at (i));
       }
-    emit settings_changed (settings);
   }


The reason I moved the emitted settings_changed() sooner is that it looked to
me that restoring the layout was emitting settings_changed() which in turn
called slots:

 
  void
  octave_dock_widget::handle_active_dock_changed (octave_dock_widget *w_old,
                                                  octave_dock_widget *w_new)
  {
    if (m_custom_style && this == w_old)
      {
        set_style (false);
        update ();
      }

    if (m_custom_style && this == w_new)
      {
        set_style (true);
        update ();
      }
  }


and m_custom_style and all the similar variables within set_style() had not
been initialized yet.  To see that this is the case, here's a dump of what's
happening, in which ALL-CAPS is what's happening inside
main_window::focus_changed() and lower case is what's happening inside
octave_dock_widget::handle_active_dock_changed():


M_ACTIVE_DOCK:0  DOCK:0xfaa5a0
m_custom_style:1  w_old:0  w_new:0xfaa5a0  this:0xd8bb10
m_custom_style:10  w_old:0  w_new:0xfaa5a0  this:0xf702b0
m_custom_style:41  w_old:0  w_new:0xfaa5a0  this:0xfaa5a0
m_custom_style:0  w_old:0  w_new:0xfaa5a0  this:0x10ffd90
m_custom_style:115  w_old:0  w_new:0xfaa5a0  this:0x1445850
m_custom_style:107  w_old:0  w_new:0xfaa5a0  this:0x141e220
m_custom_style:47  w_old:0  w_new:0xfaa5a0  this:0x14a38b0
M_ACTIVE_DOCK:0xfaa5a0  DOCK:0xd8bb10
m_custom_style:1  w_old:0xfaa5a0  w_new:0xd8bb10  this:0xd8bb10
m_custom_style:10  w_old:0xfaa5a0  w_new:0xd8bb10  this:0xf702b0
m_custom_style:41  w_old:0xfaa5a0  w_new:0xd8bb10  this:0xfaa5a0
m_custom_style:0  w_old:0xfaa5a0  w_new:0xd8bb10  this:0x10ffd90
m_custom_style:115  w_old:0xfaa5a0  w_new:0xd8bb10  this:0x1445850
m_custom_style:107  w_old:0xfaa5a0  w_new:0xd8bb10  this:0x141e220
m_custom_style:47  w_old:0xfaa5a0  w_new:0xd8bb10  this:0x14a38b0
M_ACTIVE_DOCK:0xd8bb10  DOCK:0xf702b0
m_custom_style:1  w_old:0xd8bb10  w_new:0xf702b0  this:0xd8bb10
m_custom_style:10  w_old:0xd8bb10  w_new:0xf702b0  this:0xf702b0
m_custom_style:41  w_old:0xd8bb10  w_new:0xf702b0  this:0xfaa5a0
m_custom_style:0  w_old:0xd8bb10  w_new:0xf702b0  this:0x10ffd90
m_custom_style:115  w_old:0xd8bb10  w_new:0xf702b0  this:0x1445850
m_custom_style:107  w_old:0xd8bb10  w_new:0xf702b0  this:0x141e220
m_custom_style:47  w_old:0xd8bb10  w_new:0xf702b0  this:0x14a38b0
M_ACTIVE_DOCK:0xf702b0  DOCK:0x10ffd90
m_custom_style:1  w_old:0xf702b0  w_new:0x10ffd90  this:0xd8bb10
m_custom_style:10  w_old:0xf702b0  w_new:0x10ffd90  this:0xf702b0
m_custom_style:41  w_old:0xf702b0  w_new:0x10ffd90  this:0xfaa5a0
m_custom_style:0  w_old:0xf702b0  w_new:0x10ffd90  this:0x10ffd90
m_custom_style:115  w_old:0xf702b0  w_new:0x10ffd90  this:0x1445850
m_custom_style:107  w_old:0xf702b0  w_new:0x10ffd90  this:0x141e220
m_custom_style:47  w_old:0xf702b0  w_new:0x10ffd90  this:0x14a38b0
M_ACTIVE_DOCK:0x10ffd90  DOCK:0x1445850
m_custom_style:1  w_old:0x10ffd90  w_new:0x1445850  this:0xd8bb10
m_custom_style:10  w_old:0x10ffd90  w_new:0x1445850  this:0xf702b0
m_custom_style:41  w_old:0x10ffd90  w_new:0x1445850  this:0xfaa5a0
m_custom_style:0  w_old:0x10ffd90  w_new:0x1445850  this:0x10ffd90
m_custom_style:115  w_old:0x10ffd90  w_new:0x1445850  this:0x1445850
m_custom_style:107  w_old:0x10ffd90  w_new:0x1445850  this:0x141e220
m_custom_style:47  w_old:0x10ffd90  w_new:0x1445850  this:0x14a38b0
M_ACTIVE_DOCK:0x1445850  DOCK:0x14a38b0
m_custom_style:1  w_old:0x1445850  w_new:0x14a38b0  this:0xd8bb10
m_custom_style:10  w_old:0x1445850  w_new:0x14a38b0  this:0xf702b0
m_custom_style:41  w_old:0x1445850  w_new:0x14a38b0  this:0xfaa5a0
m_custom_style:0  w_old:0x1445850  w_new:0x14a38b0  this:0x10ffd90
m_custom_style:115  w_old:0x1445850  w_new:0x14a38b0  this:0x1445850
m_custom_style:107  w_old:0x1445850  w_new:0x14a38b0  this:0x141e220
m_custom_style:47  w_old:0x1445850  w_new:0x14a38b0  this:0x14a38b0
M_ACTIVE_DOCK:0x14a38b0  DOCK:0x141e220
m_custom_style:1  w_old:0x14a38b0  w_new:0x141e220  this:0xd8bb10
m_custom_style:10  w_old:0x14a38b0  w_new:0x141e220  this:0xf702b0
m_custom_style:41  w_old:0x14a38b0  w_new:0x141e220  this:0xfaa5a0
m_custom_style:0  w_old:0x14a38b0  w_new:0x141e220  this:0x10ffd90
m_custom_style:115  w_old:0x14a38b0  w_new:0x141e220  this:0x1445850
m_custom_style:107  w_old:0x14a38b0  w_new:0x141e220  this:0x141e220
m_custom_style:47  w_old:0x14a38b0  w_new:0x141e220  this:0x14a38b0
m_custom_style:1  w_old:0  w_new:0x141e220  this:0xd8bb10
m_custom_style:1  w_old:0  w_new:0x141e220  this:0xf702b0
m_custom_style:1  w_old:0  w_new:0x141e220  this:0xfaa5a0
m_custom_style:1  w_old:0  w_new:0x141e220  this:0x10ffd90
m_custom_style:1  w_old:0  w_new:0x141e220  this:0x1445850
m_custom_style:1  w_old:0  w_new:0x141e220  this:0x141e220
m_custom_style:1  w_old:0  w_new:0x141e220  this:0x14a38b0
M_ACTIVE_DOCK:0x141e220  DOCK:0xd8bb10
m_custom_style:1  w_old:0x141e220  w_new:0xd8bb10  this:0xd8bb10
m_custom_style:1  w_old:0x141e220  w_new:0xd8bb10  this:0xf702b0
m_custom_style:1  w_old:0x141e220  w_new:0xd8bb10  this:0xfaa5a0
m_custom_style:1  w_old:0x141e220  w_new:0xd8bb10  this:0x10ffd90
m_custom_style:1  w_old:0x141e220  w_new:0xd8bb10  this:0x1445850
m_custom_style:1  w_old:0x141e220  w_new:0xd8bb10  this:0x141e220
m_custom_style:1  w_old:0x141e220  w_new:0xd8bb10  this:0x14a38b0
>> M_ACTIVE_DOCK:0xd8bb10  DOCK:0xfaa5a0
m_custom_style:1  w_old:0xd8bb10  w_new:0xfaa5a0  this:0xd8bb10
m_custom_style:1  w_old:0xd8bb10  w_new:0xfaa5a0  this:0xf702b0
m_custom_style:1  w_old:0xd8bb10  w_new:0xfaa5a0  this:0xfaa5a0
m_custom_style:1  w_old:0xd8bb10  w_new:0xfaa5a0  this:0x10ffd90
m_custom_style:1  w_old:0xd8bb10  w_new:0xfaa5a0  this:0x1445850
m_custom_style:1  w_old:0xd8bb10  w_new:0xfaa5a0  this:0x141e220
m_custom_style:1  w_old:0xd8bb10  w_new:0xfaa5a0  this:0x14a38b0
>> M_ACTIVE_DOCK:0xfaa5a0  DOCK:0xd8bb10
m_custom_style:1  w_old:0xfaa5a0  w_new:0xd8bb10  this:0xd8bb10
m_custom_style:1  w_old:0xfaa5a0  w_new:0xd8bb10  this:0xf702b0
m_custom_style:1  w_old:0xfaa5a0  w_new:0xd8bb10  this:0xfaa5a0
m_custom_style:1  w_old:0xfaa5a0  w_new:0xd8bb10  this:0x10ffd90
m_custom_style:1  w_old:0xfaa5a0  w_new:0xd8bb10  this:0x1445850
m_custom_style:1  w_old:0xfaa5a0  w_new:0xd8bb10  this:0x141e220
m_custom_style:1  w_old:0xfaa5a0  w_new:0xd8bb10  this:0x14a38b0


Notice how m_custome_style is some random value for all the
octave_dock_widgets in the first pass.  Then after the "emit settings_changed
(settings)" the m_custom_style has been initialized.  The issue with the
change I made (which ostensibly initializes the variables first) is that not
having the octave_dock_widget::handle_settings() call *after* the layout meant
the File Browser was left highlighted when it shouldn't have been (until
activating and deactivating corrected the matter).  That because at the end of
octave_dock_widget::handle_settings() is the following:


#endif

    notice_settings (settings);  // call individual handler

    set_style (false);
  }


That is, the set_style(false) resets the octave_dock_widget highlight state to
off.  Whether this should be done is one question, but it looks like currently
some other code is doing a re-activate of m_active_dock after a
"Preferences...", so that is covered.

In summary, the issue is mainly that m_custom_style, m_bg_color_active,
m_fg_color_active, m_icon_color_active, m_bg_color, m_fg_color, and
m_icon_color are being used via main_window::read_settings() before they are
initialized to anything.  I suppose the worst consequence of this is that the
octave_dock_widgets are (non-visibly) being assigned random colors that are
then overwritten just prior to making the whole application visible.  In other
words, this doesn't appear to be a segfault type of issue.  One approach would
be to issue


+    emit settings_changed (settings);


both before and after the a layout code (the first initializes the
m_custom_style, etc. and the second clears all the highlights).  However,
probably the more proper thing to do is to initialize the m_custom_style, etc.
in the octave_dock_widget::octave_dock_widget() constructor.




    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]