A few design questions...

[mzimmers]

Hmm...well, then it should have worked, no?

What totally obvious thing am I overlooking? I could post the entire .pro file if that would help.

[goetz]

Yep, it should have worked. Is the QML file in a subdirectory?

You can try with a test file like this:

@
APP_QML_FILES.files = Makefile
APP_QML_FILES.path = Contents/Resources
QMAKE_BUNDLE_DATA += APP_QML_FILES
@

Not that a Makefile in the Resources is very useful, but it serves well for demonstration purposes :-)

For another test, you could add the absolute path to the QML to APP_QML_FILES.files.

And as a third guess, do you use shadow builds?

[mzimmers]

QML file is in same directory as .pro file.

Regarding adding the absolute path: I'll re-ask my question of whether there's a way to do it symbolically. Otherwise, it doesn't really solve the problem.

Shadow builds: I have a parallel directory to my source, called NNN-build-desktop. That's where all my built files go to live. Is that a shadow build, and if so, is it a bad thing, and if so, how do I do something else?

Thanks.

[goetz]

I don't know about a function that returns the path of the .pro file. As far as I remember this question raised in the forums some time ago.

Shadow builds are not a problem. I just checked with my test project. (EDIT: yep, the parallel directory is a shadow build)

It must be something different, probably a typo or so. You can post the .pro file here and the contents of your directory, so we can check again. If you don't want to expose your data publicly, contact me via private message to negotiate a "secure" channel.

[mzimmers]

No, I think it's safe to share filenames, for now at least.

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/Resources
QMAKE_BUNDLE_DATA += APP_QML_FILES

QT += 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
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

FORMS +=
widget.ui

OTHER_FILES +=
DemodShaperFilter.qml
@

And here's a snapshot of my directory:

!http://www.scopedin.com/images/screen.jpg(directory)!

Thanks...

[mzimmers]

I found the problem: Contents/Resources isn't where the executable is; it's in Contents/MacOS. Works fine now.

That was a nice diversion; now I'll get back to trying to do what Zap mentioned several posts ago. I'll be back with questions about that soon.

[mzimmers]

So, Zap: from reading the section on Q_PROPERTY, it appears that within my top-level class, I replace the variable creation with a Q_PROPERTY. So, instead of:

@int combGainI;@

I'll now have something like:

@ Q_PROPERTY (int combGainI READ readFn WRITE writeFn);
@

Correct so far?

So, since I have to supply a read and write function, am I correct in assuming that this can no longer be an int? I have to make a class for the combGain, and provide gets and sets for it?

Thanks.

[ZapB]

You need the Q_PROPERTY declaration as well as not instead of your normal member variable declaration. This aspect yoru class might look something like this:

@
class MyClass : public QObject
{
Q_OBJECT
Q_PROPERTY( int combGainl READ combGainl WRITE setCombGainl NOTIFY combGainlChanged )

public:
...
void setCombGainl( int combGainl )
{
// Only emit signal if new value is different
if ( m_combGainl == combGainl )
return;
m_combGainl = combGainl;
emit combGainlChanged( m_combGainl );
}

int combGainl() const { return m_combGainl; }

signals:
void combGainlChanged( int );

private:
int m_combGainl;
};
@

The important aspects here are:

You still need to decalre the member as usual

You need to provide a getter method

If you declare the property as writeable (from outside the class) as I have illustrated here, then you must provide a setter function too. It is important (to minimise updates and to break circular dependencies between bound properties) that the setter function only emits the property changed notification signal when it does actually change.

If the variable exposed as a property is purely calculated internally then you do not need to expose it as a writeable property. However, you do need to emit the combGainlChanged( int ) signal when you calculate a new value for it. This is used by the QML framework to update QML items that have properties bound to this property.

I hope all of that makes sense. It will become clear when you get your first C++/QML example working.

As for the property types, you can use any type known to Qt's metatype system (look up Q_DECLARE_METATYPE and qRegisterMetaType in the docs). So all the built in types (int, double, etc. plus all the types handled by QVariant work fine out of the box).

[goetz]

[quote author="mzimmers" date="1301619372"]I found the problem: Contents/Resources isn't where the executable is; it's in Contents/MacOS. Works fine now.

That was a nice diversion; now I'll get back to trying to do what Zap mentioned several posts ago. I'll be back with questions about that soon.[/quote]

But it got copied into Contents/Resources?

A good way would be to put it there and adapt the search paths in your application (wrapped in some #ifdef):

@
#if defined( Q_OS_MACX )
declarativeEngine.addImportPath(qApp->applicationDirPath() + "/../Resources");
#endif
@

(I've not tested it, you might use another path setter/adder for this)

[mzimmers]

Zap: that's a very good explanation. I'm still unclear on the combGainIChanged function, though. Do I actually implement this, or is it part of the BFM of Qt? I ask because I don't see an analog for it in the code we did in the other thread.

It seems that I'm not yet tying data to a display item, too...is that the next step?

EDIT:

Another question: can the combGainI stuff be adapted to be general-purpose, or do I need to replicate this for each variable I wish to display with QML?

[mzimmers]

Hey, Volker:

Just to be sure I was clear: when qmake runs, it puts the executable into Contents/MacOS, not into Contents/Resources. So, I just modified my .pro file accordingly:

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

Unless I'm missing something, I don't see a downside to putting the .qml file (and other needed files) into the same directory as the executable...

[goetz]

In theory, Contents/MacOS conatains the executable(s), and Contents/Resources would be the place to put QML files. It's not really harmful, to put resources like QMLs into Contents/MacOS too. The only drawback is that it is not best practise on OS X and that Apple recommends Contents/Resources.

What makes me wonder, is how qmake puts that files into the wrong dir. Assuming there are two files QuickTest.qml and TestPage.qml within the same directory as the .pro file, the following snippet puts it into Contents/Resources:

@
APP_QML_FILES.files = QuickTest.qml TestPage.qml
APP_QML_FILES.path = Contents/Resources
QMAKE_BUNDLE_DATA += APP_QML_FILES
@

You might want to remove the application bundle directory before building, as qmake just adds files, but does not remove them!

[ZapB]

[quote author="mzimmers" date="1301678701"]Zap: that's a very good explanation. I'm still unclear on the combGainIChanged function, though. Do I actually implement this, or is it part of the BFM of Qt? I ask because I don't see an analog for it in the code we did in the other thread.
[/quote]

No you do not need to implement it. The implementation of signals is generated automatically for you by the moc step of the build process. When you run qmake, it scans the files listed in the HEADERS section for class containing Q_OBJECT. It adds rules to the generated Makefile to run these headers through the Qt moc tool. The moc generates the moc_*.cpp files that you will find in your build tree. The signal/slot and other metaobject magic is implemented in these files.

[quote author="mzimmers" date="1301678701"]
It seems that I'm not yet tying data to a display item, too...is that the next step?
[/quote]

Yes we will tackle that next. A swim and some food first for me though ;-)

EDIT:

[quote author="mzimmers" date="1301678701"]
Another question: can the combGainI stuff be adapted to be general-purpose, or do I need to replicate this for each variable I wish to display with QML?[/quote]

That depends on what you want to do. You need to expose all properties that you wish to access from QML in this way. If you have a lot of data then there are alternative approaches using a subclass of QAbstractListModel for example.

Which approach to use depends upon how you structure your code. From what you have said earlier it sounded like you will have an object hierarchy, so it may be simplest to expose a member or two from each object as properties in this way. If you have a class with 20 such data items then it may pay you to look into the model approach for that case.

It will become clearer as we progress...

[mzimmers]

OK...I've implemented the stuff in the post above. Is there any way to verify it at this point, or do we just go to the next step?

[ZapB]

You can verify what you have done so far by converting your original GUI to use the new property changed signals instead of the original dataChanged( int, int ) signal. So if you now have two properties, one for each of the two variables, then you will need to make two connections - one for each property notifier signal.

Another way of verifying that it works would be to make use of the QTestLib framework and write a unit test for your class. In such tests you can make use of QSignalSpy to ensure that the signals were emitted as expected. Unit tests are nice as they can be run at any time in the future if you need to convince yourself that a certain part of your codebase is still working as it should.

Once you have verified that you calculation works as it should you can start putting together your QML scene that will display the state of your calculation object's properties. See if you can have a go at that from what you find in the QML examples. At this stage we don't need anything extravagant, just a couple of rectangles and text elements should suffice. Let us know if you need a hand with this.

[mzimmers]

Just got back to this stuff. So, if I understand your first paragraph above, I want to change this line in widget.cpp:

@ connect (soc, SIGNAL(dataChanged(int, int)), this, SLOT(setValue(int, int)));@

to:

@ connect (soc, SIGNAL(combGainIChanged(int)), this, SLOT(setCombGainI(int)));@

Is this right? If so, what should I expect to see happen?

EDIT:

Actually, instead of changing that line, can I just add the second line (if correct)? For now, I might as well keep the original GUI working, too.
Thanks.

[ZapB]

Yes replace the original line with the second one that you posted. Then you need to implement the slot setCombGainI(int) such that it updates that value in your GUI.

You would then need a corresponding slot for any other variable, combGainQ say.

If you keep the original connections how can you know that your new signals are being emitted when they should be and with the right values?

I would seriously consider adding a simple unit test. Have a read of the QTest Framework docs. They have a nice "tutorial":http://doc.qt.nokia.com/latest/qtestlib-tutorial.html that explains it all. Trust me it can be very surprising what unit tests can show up in the course of testing. As long as you writie good tests they are very valuable things to have around.

[mzimmers]

[quote author="ZapB" date="1301904635"]Yes replace the original line with the second one that you posted. Then you need to implement the slot setCombGainI(int) such that it updates that value in your GUI.[/quote]

Right, and this is the missing ingredient, isn't it? Currently, setCombGainI() emits this:

@ emit combGainIChanged (combGainI);@

So, what do I do now to "tie together" the code and the GUI?

[quote]You would then need a corresponding slot for any other variable, combGainQ say.[/quote]

Yeah, I figured I'd get one right and then do the other.

[quote]If you keep the original connections how can you know that your new signals are being emitted when they should be and with the right values? [/quote]

I guess I'm missing something. I thought if I maintained the two GUIs, I could verify the new one by comparing its results with the original. Plus, I still have the console output. Or, is this not what you're asking?

[quote]I would seriously consider adding a simple unit test. Have a read of the QTest Framework docs. They have a nice "tutorial":http://doc.qt.nokia.com/latest/qtestlib-tutorial.html that explains it all. Trust me it can be very surprising what unit tests can show up in the course of testing. As long as you writie good tests they are very valuable things to have around.[/quote]

I'll do this, I promise. I just thought it would be better for me to have a little better grasp of what I'm doing here before I went about designing a test for it.

Thanks.

[ZapB]

[quote author="mzimmers" date="1301916754"][quote author="ZapB" date="1301904635"]Yes replace the original line with the second one that you posted. Then you need to implement the slot setCombGainI(int) such that it updates that value in your GUI.[/quote]

Right, and this is the missing ingredient, isn't it? Currently, setCombGainI() emits this:

@ emit combGainIChanged (combGainI);@
[/quote]

I meant that you need to implement a setCombGainI( int ) slot on your GUI class (Widget in the original example). This should modify the text string passed to the QLabel.

As far as being able to maintain your old working GUI I suggest that you do the new work in a branch of your version control system. Then you can go back and forth between the old method and the new one at will.

BTW having a unit test for the calculation part (the class with the properties) does not mean you abandon the existing GUI code. The unit test becomes an executable that exists parallel to your GUI binary. It's just that it tests one aspect (usually one class) of your code-base.

[mzimmers]

I meant that you need to implement a setCombGainI( int ) slot on your GUI class (Widget in the original example). This should modify the text string passed to the QLabel.

OK, so I'm going to modify setValue, right? Apart from (temporarily) changing it to work with only one variable, what else am I going to do? It still seems like I'm missing the "hook up" to a "real" GUI. Am I still going to use the ui->label->setText call for this?