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

[Daniel J Sebald]

On 02/08/2018 01:13 PM, John W. Eaton wrote:
> 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?

Yes, it's what was originally chosen.  I don't want to start from fresh, 
i.e., a QObject, because I'm not (and I don't think anyone is) willing 
to code the whole behavior of a window.  But QMainWindow has some nice 
features.  Recall, it has a central widget and around the outside of the 
central widget is dockable widgets that snap into place and line 
everything up.  That's a nice behavior, and additionally it has the 
ability to stack windows in a tabified format--so it is a combination of 
tabs and multiple views.

By shrinking the central widget to nothing, all one sees are the docked 
tables for various variables.  Works well enough.  [As a next possible 
feature, I've made the central widget an QMdiArea.  MDI means the 
widgets it contains can be arranged in any overlapping fashion, but then 
one can tell the MDI to tile the windows.  Maybe some people would like 
that behavior instead, so there could possibly be a Preference setting 
for whether one wants the central-widget behavior or the MDI behavior. 
That's getting too far ahead though without some smaller steps first.]


> 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

There's variation in these sorts of things.  Is it clearer?  Don't know, 
it's more a case of getting in tune with the design.  What the above 
does do is centralize the type of child, i.e., there wouldn't then be 
variable_editor_widget in a template anywhere but here.  But if you 
think of it, one would be coding

variable_editor_widget *mywidgetptr = mymainptr->find_variable(name);

so right there we are already using "variable_editor_widget" as the 
return type so using

variable_editor_widget *mywidgetptr =
    mymainptr->findChild<variable_editor_widget *> (name);

isn't restricting things much more.  Could involve more assembly code, 
perhaps.


>    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.

I could change that to search for (more generally) QWidget or QObject or 
(less generally) variable_dock_widget, which I think I do in a couple 
other spots.  I started out more generally because I saw that--depending 
on the contents of the variable--there could be a sub-editor opened and 
I didn't know what type of object that would be.


> 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.

I don't think it should be a problem.  The use of the object names is 
resident to the m_main... yes, m_main is the Variable Editor main 
window.  So, as you say, it is only looking at names for objects 
contained within that window.  There could be objects somewhere else in 
the GUI with possible variable names (e.g., in the qt_creator are 
probably names like "label1", "label2", etc.) but so long as they aren't 
contained within the Variable Editor, that's fine.  But the Variable 
Editor is dynamically built and the routine is the one providing the 
names.  There's even further control of telling findChildren() to only 
look one level deep and not continue further, i.e., don't look for the 
names of QLabel, QViewTable, QModel, etc.

Dan