Re: renaming some classes and using the octave namespace in the GUI

[John W. Eaton]

On 02/08/2018 01:30 PM, Daniel J Sebald wrote:

> If the overall design is changed, just change 
> QDockWidget to something else, and then one isn't constrained by the 
> whole m_tab_widget pointer approach.

If you are concerned about that, then don't start by using QDockWidget. 
Use a class name that you choose, derived from some Qt object.  Then 
this code doesn't have to change at all even if you change the actual 
implementation of the widget that contains the variable display.  For 
what follows, I'll call this class "variable_editor_widget".

What is the type of m_main?  Is it a QMainWindow?

If instead, we also define that as our own class derived from 
QMainWindow (or whatever, let's call it variable_editor_main_window) 
then you could add a method to it like this:

  variable_editor_widget *
  variable_editor_main::find_variable (const QString& name)
  {
     return findChild<variable_editor_widget *> (name);
  }

I don't know.  Is that clearer?  I would rather see

  variable_editor_widget *vew = m_main->find_variable (name);

instead of

  QDockWidget *existing_qdw = m_main->findChild<QDockWidget *> (name);

With the former, it seems clear that the code is looking for a variable. 
 All I can tell from the latter is that it is looking for a dockwidget 
object and I don't know why.

OTOH, if this is only used in one place (inside variable_editor), then 
maybe what I'm proposing above is adding an extra layer that is not 
really needed.

Anyway, I agree that findChild is better than iterating over a list of 
tabs.  I would just like to be sure that overloading the object name for 
the purpose of finding variables won't cause confusion later.

jwe