A few design questions...

[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:

1. add some control buttons for start/stop/step
2. 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.

[andre]

[quote author="mzimmers" date="1302051296"]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.
[/quote]
That's how Quick works: it automatically creates a camelcase name for the signal.

[quote]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?[/quote]
There is no established practice for that. QML is too new, and the designer is very new too. Do whatever feels right to you: modify your design in "code" (QML) or visually.

[mzimmers]

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.

[andre]

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

[mzimmers]

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?

[andre]

[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 :-)

[mzimmers]

[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?

[andre]

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

[mzimmers]

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?

[andre]

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.

[mzimmers]

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.

[ZapB]

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

[mzimmers]

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.

[ZapB]

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.