[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: renaming some classes and using the octave namespace in the GUI
From: |
Daniel J Sebald |
Subject: |
Re: renaming some classes and using the octave namespace in the GUI |
Date: |
Thu, 8 Feb 2018 14:50:47 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
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
Re: renaming some classes and using the octave namespace in the GUI, Torsten, 2018/02/08