A few design questions...

ZapB

Now let's consider the declarative approach. Looking at the Widget constructor again, we see that we get a pointer to the declarative view. Using this pointer we first expose our m_generator member variable to the world of QML by using the QDeclarativeContext associated with the view:

@view->rootContext()->setContextProperty( "generator", m_generator );@

This is a very important line. What this means is that within the qml file that we use the actual member variable m_generator from C++ will be available to use in the qml file as an object called "generator".

Think about that for a moment as this is the crucial part of linking our familar world of C++ with the brave new world of QML. The implications in this case are that we can bind properties of QML elements to javascript expressions including references to properties of the "generator" object. If our "generator" object also had writable properties we could set those properties from within QML too.

With this in mind it should be clear that the "generator" object and the API of the Generator class form the programming interface to our application for QML. When exposing objects to QML (or QtScript) it pays to think about what objects you should expose and what properties and invokable functions those objects should have. Choosing wisely is a key to a good design and a clean interface between C++ and QML/javascript.

OK, now that we have exposed the "generator" object (m_generator in C++) we can now proceed to load a qml file:

@
view->setSource( QUrl( "qrc:/simple.qml" ) );
@

Here I have decided to compile the qml file into the application to avoid the resource location issues that you know all about ;-) The contents of the resource file, simple.qrc are trivial:

@
<RCC>
<qresource prefix="/">
<file>simple.qml</file>
</qresource>
</RCC>
@

Now let's look at the actual content of the QML file. I simply added a new qml using qt-creator and edited it to look like this:

@
import QtQuick 1.0

Rectangle {
id: myRect
width: 100
height: 62
color: "#008000"

Text {
    // Here we use the expose "generator" object to set the text
    text: "CombGainI = " + generator.combGainI;
    anchors.centerIn: parent
}

Connections {
    target: generator
    onCombGainIChanged: {
        // This is not very declarative way of toggling the color but
        // this is just to show how simple it is to do things
        if ( myRect.color == "#008000" )
            myRect.color = "#ff0000";
        else
            myRect.color = "#008000";
    }
}

}
@

As you can see this is a very trivial QML file for demonstration purposes. It consists of a Rect item and within that a Text item. The Rect item has an id of "myRect" so that we can refer to it from elsewhere in the file. We set soem basic dimensions and then set the color to green.

Look carefully at the Text item. The line anchors.centerIn: parent simple tell the layout system to centre the text item in it's parent ie myRect. The magic line though is:

@text: "CombGainI = " + generator.combGainI;@

This establishes what is known as a "property binding". That is, the text property of the Text element is bound to the javascript expression which concatenates the string "CombGainI = " and the combGainI property of the "generator" object that we exposed in the constructor of the Widget class.

Once you have declared this property binding the QML framework does some bookkeeping and notices that the text property is dependent upon the "generator" object's combGainI property. It is kind enough to put in some glue such that anytime the combGainI property changes (and emits the notifier signal) the expression is re-evaluated and the text property updated.

That is the other part of the magic bridge between the worlds of C++ and QML. So to summarise the two aspects are:

Expose objects that have properties from C++ to QML using QDeclarativeContext::setContextProperty()

Use those exposed object's properties in property bindings in your QML documents.

I have added a little extra at the end of the simple.qml file that shows one way in which the background colour of the rectangle, myRect, can be toggled as a result of the combGainI property changing. In this case it is simply toggled between green and red.

When you build and run this example you should see the QLabel and the QML scene changing to show the new value of combGainI once every second. The rect in the QML scene will also flip between red and green.

Anyway that is the end of this long post. I hope it gives you an basic idea of how to couple C++ and QML together in order to display data calculated in C++ in a GUI written with QML.

It is a lot to take in at first but I have tried to highlight the important concepts. Feel free to come back with questions if you have any.

Happy hacking.

mzimmers

Hey, Zap -

Thanks a ton for all this work. I will have more questions soon, I'm sure, but right now...I don't see how to go about editing the .qrc file. I've created it, but it won't let me put anything in it. Advice?

Thanks again.

EDIT:

I might as well mention some build errors:

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

is giving this:

bq. error: invalid use of incomplete type 'struct QDeclarativeContext'

soc is an instance of my Soc class; I've been using that instead of the m_generator variable. Did I mess this up?

I'm getting a similar error for QKeyEvent.

Thanks...

ZapB

Ah sorry I realised as I was going to sleep last night that I missed a trivial but important aspect to get this to build - you need to edit the .pro file so that it includes the line:

@QT += core gui declarative@

and re-run qmake. This will then tell qmake to add directives to the Makefile to allow the compiler and linker to find the QtDeclarative headers and libraries. Sorry about that.

To edit the .qrc file, just click on it in qt-creator. This will open it in the resource editor. Click on the "Add" button and choose "Add prefix". Then edit the prefix to "/" in the line edit below. Then click on "Add"->"Add Files..." and in the file dialog choose your .qml file. That's it. Your .qml file will now get compiled into your application.

Don't forget to add:

@
#include <QDeclarativeContext>
#include <QKeyEvent>
@

in your .cpp file.

ZapB

To make things easier I have uploaded a tarball of the example to my "webserver":http://www.theharmers.co.uk/simpletest.tar.gz. Just download it, unpack it and run qmake && make.

mgran

Kudos ZapB, good stuff :)

ZapB

Thank you Marius. If there is interest, I'll redo this and the pre-cursor as tutorials on the wiki.

mgran

[quote author="ZapB" date="1301993122"]Thank you Marius. If there is interest, I'll redo this and the pre-cursor as tutorials on the wiki.[/quote]

Would be nothing short of fantastic if you could do that :) Cheers!

ZapB

Hmmm, OK I think I feel a little tutorial series coming on. ;-)

mzimmers

I'm still getting one compiler error, and as fate would have it, it's on the line you described above as "very important."

First, a bit of context may be helpful. Here's the private section of my Widget class:

@private:
Ui::Widget *ui;
QTimer *m_timer;
Soc *soc;@

So, soc is what I'm using instead of m_generator. It's the top-level class/data structure in my program.

In widget.cpp, this line is giving me an error:

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

[quote]error: invalid use of incomplete type 'struct QDeclarativeContext'
/Library/Frameworks/QtDeclarative.framework/Versions/4/Headers/qdeclarativeview.h:59: error: forward declaration of 'struct QDeclarativeContext[/quote]

What did I do wrong? Thanks.

ZapB

Sounds like you missed the line:

@#include <QDeclarativeContext>@

mzimmers

[quote author="ZapB" date="1302014795"]Sounds like you missed the line:

@#include <QDeclarativeContext>@[/quote]

Awcrud. You're right. So, do I still need both QDeclarativeView, or does QDeclarativeContext include that for me?

By the way, I followed your instructions on the creation of the .qrc file. I think it worked OK, but it doesn't look like your example above. It just has two lines: the slash and the filename. Not sure if that's a problem.

Thanks!

ZapB

My example only used:

@#include <QDeclarativeContext>@

The header for the view is included by the generated ui code.

Wrt to the qrc file, I am not sure. Try it and see what happens ;-) If the worst happens just download my entire example from "here":http://www.theharmers.co.uk/simpletest.tar.gz

mzimmers

Seems to work fine.

I just realized that I'd chosen the wrong variable(s) to display via the GUI. This will give me a good chance to see whether I understand this stuff enough to correctly change the program. Once I get this fixed, I'll report back, and we can talk about the next step, if that's OK with you.

EDIT:

Something I've been meaning to ask: what's the purpose of the convention of naming object elements with the "m_" prefix?

ZapB

The "m_" prefix is a subset of Hungarian notation that I choose to use as it helps me distinguish between local and member variables. I also use "ms_" prefix for static member variables. I do not bother encoding the type into the variable name as is done with full Hungarian notation though.

It's just a question of style. Other people will use different conventions.

What is your next step that you want to achieve?

Edit: NB Qt does not use Hungarian notation in its code base.

mzimmers

So, I've gone through my various files, changing that variable name. The program compiles OK, but on launch, I get a message:

bq. Object::connect: No such signal Soc::shaperOutIChanged(int) in ../simulatorGUI/src/widget.cpp:18

shaperOutIChanged used to be combGainIChanged...I believe you told me this was automatically generated. Any idea what I did wrong here? I can post code if you want.

Thanks.

Oh, as far as next steps: we could go one of two ways:

add some control buttons for start/stop/step
make the display a little more "graphic" (once it works)...maybe using the LCD display widget if that's possible?

ZapB

The implementation of signals is done for you but your still need to declare them in the signals: section of your class. The notifier signal does not have any arguments. It is simply a signal to tell the world that the property has changed.

Can you post your header file for the Soc class please?

Before we can go to the next step you need to decide how you wish to construct your GUI:

QWidget based only.

QML only.

Mixture of QWidget (e.g. for file menu, tool bars) and QML (perhaps for the main visualisation part).

You could also choose to use QGraphicsView in place of QML and a QDeclarativeView.

The choice is yours. You have seen examples of how to connect up QWidget-derived GUI elements and QML items to your C++ computational object's properties. Let us know which route you wish to follow and we'll see what we can do.

If I were in your position I would be tempted by option 3, but that's just me. Options 1 and 2 are equally valid.

mzimmers

Here's my soc.h file (with some unessential stuff removed):

@#ifndef SOC_H
#define SOC_H

#include <QObject>

class Soc : public QObject
{
Q_OBJECT
Q_PROPERTY (int shaperOutI
READ getShaperOutI WRITE setShaperOutI NOTIFY shaperOutIChanged)

public:
explicit Soc(QObject *parent = 0);
int getShaperOutI() const;
void setShaperOutI(int i);

public slots:
void runOneCycle();

signals:
void shaperOutIChanged ();

private:
DemodShaperFilter filter; // one shaper filter for now
SystolicFilter sf;

};
#endif // SOC_H
@

--

Before I decide on which option to go, I'd like to get this cleaned up. I'm probably just going to go with 2 or 3, though.

Thanks.

mzimmers

Update: I reread your post above, and discovered that I'd missed the part about no arguments to the notifier signal. That got me halfway home. The other problem was in my .qml file, specifically this line:

@ onShaperOutIChanged: {
@

I had put a small "s" on shaper, since that's the precise (non)capitalization of the routine name, but it didn't like that. (The error message scrolled past too quickly for me to notice at first.) Replacing it with a capital "S" makes it work...but I don't understand why. If you could shed some light on this, that would be great.

Now that it's working, I'd like to start playing with the formatting of the display. Is this typically done in design mode, or just by editing the QML file? I'd like to change the size of the inner rectangle, the color(s) of the background, text placement, that kind of stuff. Probably through Design mode, right?

ZapB

You connect statement does not match the signature of your signal. The error message you posted implies that you used an int as an argument in the connect but your header file shows the signal has no arguments (as indeed it should not).

Change your connect statement that hooks up to the shaperOutIChanged() signal to have no mention of an int argument.

mzimmers

Hi, Zap -

I got that issue fixed. When you get time, I'd appreciate your feedback on the questions I posted above. I think I'm about ready to consider this thread solved.

Thanks for all the help.