Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

A few design questions...



  • OK, thanks, Andre. So, to try to sum this all up, it appears that in this thread, we've explored two ways to create and maintain UIs: using a widget, and using the PROPERTY macros.

    Does the use of the latter method obviate the need for the former?

    And, if I want to duplicate the QML method for displaying a second value, that means that I duplicate:

    • the Q_PROPERTY macros
    • the methods for setting/getting the member variable (and its string)
    • the connect statement within the Soc constructor

    Did I leave anything out?

    Thanks.



  • [quote author="mzimmers" date="1302193514"]OK, thanks, Andre. So, to try to sum this all up, it appears that in this thread, we've explored two ways to create and maintain UIs: using a widget, and using the PROPERTY macros.[/quote]
    Those are not two different ways of creating UI's. Both are techniques very different techniques, and you can use them together.
    [quote]
    Does the use of the latter method obviate the need for the former?
    [/quote]
    No, not even if you compare QML with QWidgets. You can also use tem together. You can create widgets using QML, for example.

    [quote]And, if I want to duplicate the QML method for displaying a second value, that means that I duplicate:

    • the Q_PROPERTY macros
    • the methods for setting/getting the member variable (and its string)
    • the connect statement within the Soc constructor

    Did I leave anything out?
    [/quote]
    That depends a bit. Every value you want to bind to in QML, needs to be a QObject property. For those, you need Q_PROPERTY macro's, including the getters, setters and change signals (which you left out). If you need the connect statement, depends on what that property does exactly. Just make sure you emit the change signal if the value changes.



  • I'm still trying to learn the terminology here. By "change signals," are you referring to the "emit" statements?

    On a side note, I notice that, in order to display one member, I've needed to add three routines to my Soc class: a get, a set and a getString. If I wanted to display, say, a dozen variables at once, that could make for a rather large source file. Do you have any tips on organizing files for this kind of application?



  • [quote author="mzimmers" date="1302197505"]I'm still trying to learn the terminology here. By "change signals," are you referring to the "emit" statements?[/quote]
    I was not making myself clear. It should have been notify signals, not change signals. And you need to emit them, obviously.

    [quote]On a side note, I notice that, in order to display one member, I've needed to add three routines to my Soc class: a get, a set and a getString. If I wanted to display, say, a dozen variables at once, that could make for a rather large source file. Do you have any tips on organizing files for this kind of application?[/quote]
    You don't always need a string version. If you need such a thing often, you can choose another method than adding a string property. Using javascript is one option, or create another simple conversino object, or... For every problem, there are multiple solutions.

    On the number of methods you need for properties: true, but they can almost all be one-liners, and from QtCreator 2.2 you can have Creator implement them for you :-)



  • [quote]I was not making myself clear. It should have been notify signals, not change signals. And you need to emit them, obviously. [/quote]

    I'm still not sure I know what you're referring to. Isn't the notify signal the one called from the set routine? And, as such, it's generated automatically (I don't write it), right? Or are you talking about something else?



  • [quote author="mzimmers" date="1302199414"][quote]I was not making myself clear. It should have been notify signals, not change signals. And you need to emit them, obviously. [/quote]

    I'm still not sure I know what you're referring to. Isn't the notify signal the one called from the set routine? And, as such, it's generated automatically (I don't write it), right? Or are you talking about something else?[/quote]

    No, that automatic generation only goes for properties you define in QML, not for properties on QObjects. Those must have notify signals defined (and emitted, of course) for the properties you want to use from QML.



  • Aargh...I'm sorry to be so dense, but I'm not connecting the dots here. This is what I know I've done to effect a QML display for a single member:

    used the Q_PROPERTY macro in the .h file for the class

    created a get and a set for this member

    declared a (member-name)Changed signal for the class...but did NOT define it

    put an emit in for this signal in a couple places in the code

    Plus, of course, all the QML formatting.

    So...what am I missing here?



  • Nothing. Seems to be complete :-)
    You don't need to define signals, Qt will do that for you (through moc). You did include the Q_OBJECT macro in your Soc class definition, I trust? If not, add it, and re-run qmake and recompile.



  • Oh, right...I guess that should go on the list, too. Thanks, Andre.

    I think I'm done with this thread. I've got some new questions, but they're more appropriate for a new thread.

    Once again, thanks to everyone who helped out an old dog trying to learn new tricks.



  • Sorry for the delay in answering, I've been out of the office and in meetings a lot.

    @mzimmers, wrt changing the QML document it is up to you how you do it. I tend to use the text editor rather than the design mode. I have not had a chance to play with the qml design mode recently so it has probably changed a great deal since I tsarted looking at qml.

    If you find yourself reusing the same pattern over and over in a qml scene then you may want to read up on factoring out the commonality into a custom qml Component. This is akin to having a class in C++.



  • Hey, Zap...if you're still getting alerts on this thread:

    I'm trying to move the Qt logic we implemented in this thread from one class (Soc) to another (Filter).

    I commented out most of the Qt code in the Soc class, but I'm getting a build error that a particular routine isn't declared in the scope of the SoC class. The problem is, it's coming from the moc_Soc.cpp file. Is this enough information for you to tell me what I might have missed?

    Thanks.



  • Can you show me your header files and the snippet of code that the compiler is complaining about please? Plus the entire compiler message would be useful too.



  • Here's the error message:

    bq. moc_Soc.cpp: In member function 'virtual int Soc::qt_metacall(QMetaObject::Call, int, void**)':
    moc_Soc.cpp:98: error: 'shaperOutIString' was not declared in this scope
    moc_Soc.cpp:104: error: 'setShaperOutI' was not declared in this scope

    Here's the code snippet from the moc_Soc file:

    @#ifndef QT_NO_PROPERTIES
    else if (_c == QMetaObject::ReadProperty) {
    void *_v = _a[0];
    switch (_id) {
    case 0: reinterpret_cast< long>(_v) = getShaperOutI(); break;
    case 1: reinterpret_cast< QString>(_v) = shaperOutIString(); break;
    }
    @

    (It's complaining about the case 1 line.)

    Header files: I'm trying to keep this post brief, but here's the header for the filter class:
    @class DemodShaperFilter : public QObject
    {
    Q_OBJECT
    Q_PROPERTY (long shaperOutI
    READ getShaperOutI WRITE setShaperOutI NOTIFY shaperOutIChanged)
    Q_PROPERTY (QString shaperOutIString
    READ shaperOutIString NOTIFY shaperOutIStringChanged)
    private:
    vector<Cell> cellArrayI;
    vector<Cell> cellArrayQ;
    long shaperOutI; // for Qt display purposes
    public:
    DemodShaperFilter(QObject *parent = 0,
    long rv = 0); // constructor w/ reset param
    DemodShaperFilter(QObject *parent = 0,
    const DemodShaperFilter &dsf = 0); // copy constructor
    ~DemodShaperFilter(); // destructor
    void cycle(long combGainI,
    long *shaperCoeffI,
    long combGainQ,
    long *shaperCoeffQ,
    bool clockEnable,
    bool resetState);
    // void testCycle();
    void reset();
    long getCoeffs(long *aI, long *aQ);
    void display();
    void setFilterClockEnable(bool n);
    long getDemShpIOut();
    long getDemShpQOut();
    long getShaperOutI() ;
    void setShaperOutI(long i);
    QString shaperOutIString();

    public slots:
    void testCycle();

    signals:
    void shaperOutIChanged ();
    void shaperOutIStringChanged ();
    };@

    Let me know what else you might need. Thanks...



  • It looks as if you still have the Q_PROPERTY() declaration in your soc.h file but that you have already removed all of the other related functionality - the setter, getter and notifier signal. Is that correct?

    Make sure you rhave no Q_PROPERTY() stuff left in the soc.h file.



  • Good eye. I removed them, and got rid of that error. Now, I'm getting:
    @Undefined symbols:
    "vtable for DemodShaperFilter", referenced from:
    __ZTV17DemodShaperFilter$non_lazy_ptr in DemodShaperFilter.o
    (maybe you meant: __ZTV17DemodShaperFilter$non_lazy_ptr)
    "DemodShaperFilter::shaperOutIChanged()", referenced from:
    DemodShaperFilter::setShaperOutI(long) in DemodShaperFilter.o
    @

    This is because I didn't change my connect commands in the widget, isn't it? Now, I have to think about this...the filter object isn't visible to the widget.



  • That type of error often occurs when you forget to:

    • include the Q_OBJECT macro (which I see you have) or
    • forget to add the header file to the HEADERS section of the .pro file or
    • forget to re-run qmake after doing so.

    Look in your build dir and see if you have a moc_demodshaperfilter.cpp being generated as part of the build process.



  • The header file is in the .pro file.

    I'm pretty sure qmake is run automatically as part of my build.

    And no, the mod_demodshaperfilter.cpp file isn't there.

    But, I think my problem is a bit more fundamental, isn't it? When we configured this originally, we set it up so that the Soc class was the "interface" to the UI. Now, though, I want to move the UI logic into the filter class, but...I don't create a new instance of the filter in widget like I do the Soc.

    I'd like the Soc class to still contain the filter (and other) class, but I'd prefer to move the UI part of the exercise closer to the actual data. The element we chose for this demonstration is part of the filter class, not the Soc.



  • No, the lack of moc_demodshaperfiler.cpp is the entire problem here (well the linker unresolved symbols error anyway). Can you post your .pro file please and try doing

    @
    make distclean
    qmake -r
    make
    @

    and post the output of the qmake and make steps please.

    With respect to exposing your DemodShaperFilter object and it's properties, that is simple. Just provide a function on your Soc class that returns a pointer to the contained DemodShaperFilter. Once you have the pointer available to your widget or qml scene then you can proceed just like we did before.



  • OK, here's the .pro file:

    @######################################################################

    Automatically generated by qmake (2.01a) Mon Mar 28 17:09:16 2011

    ######################################################################

    TEMPLATE = app
    TARGET =
    DEPENDPATH += . headers src
    INCLUDEPATH += . headers

    APP_QML_FILES.files = DemodShaperFilter.qml
    APP_QML_FILES.path = Contents/MacOS
    QMAKE_BUNDLE_DATA += APP_QML_FILES

    QT += core gui declarative

    Input

    HEADERS +=
    headers/clock.h
    headers/DemodShaperFilter.h
    headers/globals.h
    headers/register_offsets.h
    headers/Soc.h
    headers/SocReg.h
    headers/widget.h
    headers/GenericCell.h
    headers/DemodCicTuner.h
    headers/SystolicFilter.h
    headers/modpredist.h
    headers/Nco.h
    headers/nyquist.h
    headers/nyquistcell.h
    headers/modshaperfilter.h
    headers/modciccomb.h
    headers/modciccombstage.h
    headers/socreg64.h
    SOURCES +=
    src/clock.cpp
    src/DemodShaperFilter.cpp
    src/filestuff.cpp
    src/globals.cpp
    src/main.cpp
    src/Soc.cpp
    src/SocReg.cpp
    src/widget.cpp
    src/GenericCell.cpp
    src/DemodCicTuner.cpp
    src/SystolicFilter.cpp
    src/modpredist.cpp
    src/nco.cpp
    src/nyquist.cpp
    src/nyquistcell.cpp
    src/modshaperfilter.cpp
    src/modciccomb.cpp
    src/modciccombstage.cpp
    src/socreg64.cpp

    FORMS +=
    widget.ui

    OTHER_FILES +=
    DemodShaperFilter.qml

    RESOURCES +=
    simple.qrc
    @

    Those commands you posted are from the shell, right? I got this error on the make command:

    bq. make: *** No rule to make target `distclean'. Stop.



  • OK just try

    @
    make clean
    qmake -r
    make
    @

    You can do it from within qt-creator via the project context menu "Clean project", "Run qmake", and "Build project" I htink are the entries.



  • OK, I did it from Creator. "Run qmake" returned this:

    @Running build steps for project simulatorGUI...
    Starting: "/usr/bin/qmake" /Users/mzimmers/wideband/SoC simulator/simulatorGUI/simulatorGUI.pro -r -spec macx-g++ QMLJSDEBUGGER_PATH=/Developer/Applications/Qt/Qt Creator.app/Contents/Resources/qml/qmljsdebugger
    The process "/usr/bin/qmake" exited normally.@

    And the build returned a whole bunch of stuff that I won't bother putting here (unless you really want it), but it did build successfully this time. And I checked the build directory, and I now have files for the filter there.

    Now, in the UI, the value displays as "undefined." And, I'm getting a couple run-time errors about "no such signal." One is on this line (in soc.cpp):

    @ connect (this, SIGNAL(shaperOutIChanged()), this, SIGNAL(shaperOutIStringChanged()));
    @

    And the other is (in widget.cpp):
    @ connect (soc, SIGNAL(shaperOutIChanged()), this, SLOT(updateShaperOutI()));
    @



  • OK. For some reason then the build system had not noticed that qmake needed to be re-run. But at least it is fixed now.

    For the signals...

    The first connect statement should now be moved into the DemodShaperFilter class since that is where we have all of the Qt property stuff now.

    The second statement should be changed to something like this:

    @
    connect (soc->demodShaperFilter(), SIGNAL(shaperOutIChanged()), this, SLOT(updateShaperOutI()));
    @

    where you need to add:

    @
    DemodShaperFilter* demodShaperFilter() const { return m_demodShaperFilter; }
    @

    to your Soc class. Note that I have used "m_demodShaperFilter" but I have not seen your Soc.h header file so you'll have to replace that with whatever you called your pointer to the DemodShaperFilter object.

    That should remove those runtime warnings.

    Incidentally, I find it useful to run with the environment variable QT_FATAL_WARNINGS=1 set. With that in place any runtiem warnings form Qt will cause your app to abort at that point which the debugger will catch so that you can inspect the stack trace. You can set the above in the Qt-Creator project settings under the RunTime Configuration tab.



  • OK. I'd already copied the first connect into the DSF, but hadn't removed it from the Soc. Now done.

    About the second one: something doesn't look right with that function definition. Either the type or the return value needs to be changed to agree with the other...

    EDIT: also, the "const" was causing the compiler to beef, so I removed it.

    And, at runtime, I now get this error:

    @qrc:/DemodShaperFilter.qml:15:2: QML Connections: Cannot assign to non-existent property "onShaperOutIChanged"@

    I didn't change my qml file; here it is:

    @import QtQuick 1.0

    Rectangle {
    id: myRect
    width: 300
    height: 100
    color: "#808080"

    Text {
    text: "shaperOutI = " + soc.shaperOutIString;
    font.pointSize: 20
    anchors.centerIn: parent
    }

    Connections {
    target: soc
    onShaperOutIChanged: {
    if (myRect.color == "#808080")
    myRect.color = "#c0c0c0"
    else
    myRect.color = "#808080"
    }
    }
    }

    @

    Do I change the target from soc to something else (like the DSF)?



  • I cleaned up some stuff, but I'm still getting this error message:

    bq. qrc:/DemodShaperFilter.qml:15:2: QML Connections: Cannot assign to non-existent property "onShaperOutIChanged"

    Any suggestions?



  • Can you post he header file of your DemonShaperFilter class, the place where you expose that object to the qml context and the QML file please?



  • Hi, Zap -

    Apart from some include files, and constant definitions, what I posted above is my complete header file for that class. I thought I copied everything necessary over from the original Soc class; did I miss something?



  • What about the part where you expose the object to the QML context? Also can you show how you get the pointer to the DemodShaperFilter object from the Soc object please? You mentioned something about not being able to use const or a pointer or something there?



  • The Soc class has a public function to return the address of the DSF object:

    @ DemodShaperFilter* demodShaperFilter() { return &filter; }
    @

    I'm not sure I remember "exposing" the DSF to QML. In my .qml file, there's a Connections block:

    @ Connections {
    target: soc
    onShaperOutIChanged: {
    if (myRect.color == "#808080")
    myRect.color = "#c0c0c0"
    else
    myRect.color = "#808080"
    }
    }
    @

    But I didn't see any code in my Soc class that tied the object to QML.



  • Somewhere we had something like:

    @
    view->rootContext->setContextProperty( m_soc, "soc" );
    @

    which should now become something like:

    @
    view->rootContext->setContextProperty( m_soc->demodSHaperFilter, "dsf" );
    @

    then in your QML scene replace all references of "soc" to "dsf".



  • Oh! That's in the widget constructor:
    @Widget::Widget(QWidget *parent) :
    QWidget(parent),
    ui(new Ui::Widget),
    m_timer(new QTimer(this)),
    soc(new Soc(this))
    {
    ui->setupUi(this);

    connect (m_timer, SIGNAL(timeout()), soc, SLOT(runOneCycle()));

    connect (soc->demodShaperFilter(), SIGNAL(shaperOutIChanged()), this, SLOT(updateShaperOutI()));

    QDeclarativeView* view = ui->declarativeView;

    view->rootContext()->setContextProperty("soc", soc);
    view->setSource(QUrl("qrc:/DemodShaperFilter.qml"));

    m_timer->start(200); // 200 ms delay between cycles (for now)
    }
    @

    And, by "QML scene," you're referring to the .qml file?



  • Yes that is what I meant. You need to make the changes that I mentioned to that line ie:

    @
    view->rootContext()->setContextProperty( "dsf", soc->demodShaperFilter() );
    @

    and in your QML file replace all mentions of "soc" with "dsf". It should work then.



  • OK, we're getting somewhere. I no longer get the error message at startup, and the QML window now comes up with the correct initial value of the variable. But...it's not updating. I have this line in my cycle loop for the object:

    @ emit shaperOutIChanged();
    @

    Which I believe should correspond with this line in my DSF constructor:

    @ connect (this, SIGNAL(shaperOutIChanged()), this, SIGNAL(shaperOutIStringChanged()));
    @

    So, I'm not sure what's missing.

    Also, I'm confused about something: why is it we're still using some Soc functions for our QML processing?
    @ ui->setupUi(this);

    connect (m_timer, SIGNAL(timeout()), soc, SLOT(runOneCycle()));

    connect (soc->demodShaperFilter(), SIGNAL(shaperOutIChanged()), this, SLOT(updateShaperOutI()));

    QDeclarativeView* view = ui->declarativeView;

    view->rootContext()->setContextProperty("dsf", soc->demodShaperFilter());
    view->setSource(QUrl("qrc:/DemodShaperFilter.qml"));

    m_timer->start(200); // 200 ms delay between cycles (for now)
    @

    Thanks.



  • Where do you emit the shaperOutIChanged() signal? Can you post that snippet of code please? Have you run it in a debugger to make sure that emit is actually called? Do you get any runtime warnings on the console output?

    Can you also post the qml file where you use this property please - although it sounds as if the QML is correct since you get an intiial value. Just sounds like the signal is not being emitted correctly which would trigger the QML engine to update the displayed value.

    The only reason we are referring to the soc object is that it is the only way we can get at the pointer to the DemodShaperFilter object. Are you using it anywhere else in relation to displaying stuff in the GUI?



  • The shaperOutIChanged() signal is (currently) in the test loop for the DSF class. It loops 1024 times, processes the object and then executes this line (within the loop):

    @ emit shaperOutIChanged();
    @

    This routine is the one automatically generated within Qt, right?

    Contents of the .qml file:

    @import QtQuick 1.0

    Rectangle {
    id: myRect
    width: 300
    height: 100
    color: "#808080"

    Text {
    text: "shaperOutI = " + dsf.shaperOutIString;
    font.pointSize: 20
    anchors.centerIn: parent
    }

    Connections {
    target: dsf
    onShaperOutIChanged: {
    if (myRect.color == "#808080")
    myRect.color = "#c0c0c0"
    else
    myRect.color = "#808080"
    }
    }
    }

    @

    The string is the conversion of the display value. As a reminder, we did this for formatting convenience. I copied all of that code directly from the Soc class to the DSF.

    And no, I don't believe the DSF object is being used anywhere else for display purposes. The Soc invokes the DSF test loop, and that's about it.

    Thanks...



  • Hi, Zap -

    I did some more debugging. The internal logic is definitely working; that is, the loop is clearly executing and the emit statement appears to be called 1024 times. Where would you suggest I look next for the disconnect here?

    Thanks.



  • Sorry for the delay, I must have missed the notification email. I'm not sure without seeing the source code. Are you able to zip it up and mail it to me so that I can take a look (I can sign an NDA if needed). Alternatively boil it right down to a very simple example that still shows the problem and send me that zip file.



  • I can zip up the relevant files and send them to you, if I had a real email address for you. You can provide it via a message if you like.

    Thanks.



  • Sent you my email address via private message.



  • Replied. Thanks a ton, Zap.



  • OK. sorted it. I'll send the corrected file to you by email but explain it here.

    Firstly in your loop in void DemodShaper::testCycle() you were emitting the signal as you said. However, you were nto actualy updating the member variable shaperOutI anywhere in that loop. So although you were emitting the signal and the QML backend was then in turn calling the property getter function, shaperOutIString(), that function was using the member variable shaperOutI which never changed from its default value of zero.

    I have changed the last part of your loop to this:

    @
    /*
    * print out the outputs of the filter for this loop iteration.
    */
    cout.setf(ios::dec, ios::basefield);
    cout << "Demod Shaper clock cycle " << i << ". ";
    cout.setf(ios::hex, ios::basefield);
    cout.fill('0');
    cout << " iOut: " << setw(8) << getDemShpIOut() <<
    ". qOut: " << setw(8) << getDemShpQOut() << "." << endl;

    setShaperOutI( getDemShpIOut() );
    

    @

    Note that I now rely on the setShaperOutI() function to emit the notifier signal - it also checks to make sure that the value really has changed.

    As an alternative to this we could simple get rid of the member variable shaperOutI and change the getter function for that property to getDemShpIOut() however if that function does expensive calculations it is probably worth keeping it how it is with the shaperOutI member variable acting as a cached value.

    With that sorted the application works fine. You can of course add a similar pair of properties for the quadrature variable and it shex representation.

    The other problem I spotted (albeit a harmless one) was in the function setShaperOutI(long i). In here the call to shaperOutIString() is completely redundant as you do not do anything with the return value. This function then becomes:

    @
    void DemodShaper::setShaperOutI(long i)
    {
    if (shaperOutI != i) // only emit signal if value has changed
    {
    shaperOutI = i;
    emit shaperOutIChanged();
    }
    }
    @

    The other thing I would change would be to alter the function:

    @
    long Soc::getShaperOutI()
    {
    return filter.getDemShpIOut();
    }
    @

    to

    @
    long Soc::getShaperOutI()
    {
    return filter.getShaperOutI();
    }
    @

    so that it uses the cached value rather than calculating it all over again when updating the QLabel. In fact thinking about it you could remove this function completely and call getShaperOutI() directly on the DemodShaperFilter object since you can get a pointer to it via the Soc class. ie:

    @
    void Widget::updateShaperOutI()
    {
    long shaperOutI = soc->demodShaper()->getShaperOutI();
    QString s = QString( "shaperOutI = %1" ).arg( shaperOutI, FIELD_WIDTH, HEX_RADIX );
    ui->label->setText( s );
    }
    @

    Now you can add in similar properties for the quadrature values and pimp up the QML scene some more to impress your boss ;-)

    Good luck!


Log in to reply