Important: Please read the Qt Code of Conduct -

A few design questions...

  • I would seriously take a look at the Qt State Machine framework (QStateMachine, QState, QAbstractTransition etc). We make heavy use of this framework for modelling and controlling hardware devices. The hierarchical nature of the nested states and transitions maps quite nicely onto physical components or behavioural modes of operation.

    I am thinking that maybe you could use this framework to model your IC and then maybe hook it up to a QGraphicsView/Scene or QML scene for the visualisation aspects.

  • Hey, Zap -

    That does look interesting, and it might be worth a closer look. For my education, though, can we put it aside and go through the same thing we did in the other thread, except making the display of the variables more "graphical?" I'd like to implement something along the lines of what I described above, even if only for the exercise. Besides, this summer, I'll be using Qt for more than a simulator. It will be a genuine GUI, and I need to learn about that.


  • You mean that you just want to learn how to display the results of your existing calculations in a more graphical way?

    If so, then I would take a look at QGraphicsView or QML. QGraphicsView is purely C++. QML is a new technology with a lot of promise. It is easy to write custom GUIs using QML but you'll need to be prepared to get to grips with exposing C++ objects to the QML side of things.

    NB: QML is actually built on top of QGraphicsView at the moment but this is likely to change in the future.

    I suggest that you have a read up on these two technologies.

  • OK, I'll do that. A quick question regarding QML: is it suitable for a desktop app? Some resources say it's intended for mobile apps.

  • QML can be used in a desktop app just fine, but it all depends on what you want to achieve exactly.

  • Of course. You can simply use you QML scene as a single widget in your app rather than the entire application GUI. Just add a QDeclarativeView to your form and set it to use the specified QML file:

    QDeclarativeView *view = new QDeclarativeView;

  • OK, thanks, Zap. I'll look at QML more closely in the morning and see if it looks like it's what I want for this.

  • Basically it is similar to what we already did in the other thread. The main difference is that instead of simply emitting a signal for your calculated values we declare those values as properties of the QObject (using the Q_PROPERTY() macro) and add a signal that is used to notify interested parties (the QML items) about changes to those property values.

    When the QML runtime gets those signals it updates the relevent items in your QML scene that have properties bound to your C++ object's properties in some way.

    It's not as hard as it sounds ;-)

  • OK, I'll start on that in a bit. A couple of questions:

    1. does using QML mean that I'm no longer using my widget.ui file, or do they work together?
    2. regarding QML: I think I may have mentioned that later this year I'll need to design a genuine GUI (for products based on the ASIC that I'm currently simulating). Is QML appropriate for applications like that as well? I ask now, because I'd like to choose one method of implementation and stick with it for both the simulator and the product GUI.


  • 1: depends on your design. If you use a QML file for your whole UI, yes. Otherwise, the QML view is just a part of your UI design, and one that would be part of the actual .ui file.

    2: to decide that, you need to tell us about the criteria, and even then it is hard for us to advise you on that. QML may be a candidate, but...

  • Thanks, Andre. Tell you what: I'll spend today playing with QML and doing some reading.

    Regarding the upcoming product GUI: think of how you configure a home DSL modem, except we (probably) won't be using a browser to reach the embedded application.

    I'll be back later with (I'm sure) some questions.

  • QML or a QWidget based GUI will work fine for that. Depends how much you want in the way of animations or how much you would like it to look native on your target platform. Having said that QML can be made to look native and we may see some native looking QML components coming out in the course of the coming year.

  • Not directly related to the thread, but I've stumbled across an issue that I've been wondering about.

    I'm running on a Mac platform. The code that Zap posted above won't work unless I move my QML file into the resource for the binary. I don't like to do this, because 1) it's a minor hassle, and 2) it seems like a maintenance issue that I don't need.

    Does Qt have any hooks for setting a default directory, or putting a prefix on files to direct them to somewhere else? I'm trying to avoid any hard-coding here, though some may be necessary.

    I did find this thread:
    "thread on setSource":

    Which seems related, but not quite the answer.

    Any advice on how to handle this?

  • I don't have a Mac to test on, but it should work. Just be sure to correctly specify the path to the qml file. Either via an absolute path or via a path relative to the location of your application executable (see docs for QDir).

  • Decisions, decisions. An absolute pathname, and I bet it won't port to other platforms. Relative pathnames seem weird here, too.

    I don't suppose Qt supplies a pathname for the project, does it? I can't see how it could, but that would solve the problem.

  • What you can do is ionstall the file besides you exe and use QCoreApplication::applicationDirPath()

  • What you can do is ionstall the file besides you exe and use QCoreApplication::applicationDirPath()

    True, but then the QML file is out of the source structure. I'm trying to preserve a separation between source files (of all kinds) and makefile output. It seems like good CM practice if nothing else. I guess I'm probably stuck with the relative pathnames, huh?

  • Typically, you design the app so it will work on target machines with installed files, not with developer structures. Make it part of the makefile to copy the file to the out dir?

  • Now THAT'S a good idea, and will obviate the issue completely. But...makefiles are automatically generated, right? How can I do this in such a way that will survive blowing away the makefile and regenerating it?

  • read the qmake docs. I'm sure there is some possibility, but I never needed that :-)

  •'s not really a qmake function, is it? Because this special behavior should survive the makefile. Is there a way to do this in the project file?

  • You can do this by defining a custom target in your .pro file. Something like this will do it:

    myresources.path = $$(MY_INSTALL_ROOT)/resources
    myresources.files = myqmlfile.qml

    INSTALLS += target myresources

    The above depends upon the environment variable $MY_INSTALL_ROOT being set. However, this hardcodes the install path.

    Instead, it is better to get rid of the $$(MY_INSTALL_ROOT) part of the path and use the DESTDIR feature of make to specify your installation root:

    @make DESTDIR=/my/installation/path install@

    That separates the install path from your project files.

  • Sorry if I seem a little slow on the uptake here -- I'm coping with multiple unfamiliar concepts. It's been over 20 years since I've used makefiles, and I'm still trying to figure out project files, qmake, QDir and other stuff.

    Zap: I like the way your approach looks. I can't find anything on DESTDIR in the docs, though. It's not clear to me how this approach obviates the hardcoding issue; it seems to just postpone it. Obviously I'm not understanding the whole thing.


  • First: Go with the Resource directory in the application bundle. That's the expected path on OS X. One should not change those things only when it is absolutely necessary.

    qmake has support for adding additional files to the bundle:

    APP_QML_FILES.files = path/to/file1.qml path/to/file2.qml
    APP_QML_FILES.path = Contents/Resources

    This installes the files to - just where it belongs on OS X :)

    EDIT: Some more background links in the new "wiki article":

  • Thanks, Volker. I realize that files should be in the application bundle, and I wasn't suggesting to do it a different way. In the back of my mind, though, I'm wondering what that bundle looks like when copied to a PC. I'm hoping it's a directory.

    Do I correctly assume the path/to refers to the path to the source code? Or is that the target?


    I tried it two ways:
    @APP_QML_FILES.files = ./DemodShaperFilter.qml
    APP_QML_FILES.path = Contents/Resources

    @APP_QML_FILES.files = DemodShaperFilter.qml
    APP_QML_FILES.path = Contents/Resources

    Neither put the file into the Resources folder. It appears that the path is required, which surprises me, because I figured that the .pro file would use its own directory as the default.

    So now, the question is: is there some slick way to derive the current path from an environment variable or something, and plug it into the .pro file automatically?

    I'm not pursuing this level of automation out of laziness; it's more a matter of having one less thing to remember when stuff gets changed.


  • [quote author="mzimmers" date="1301602502"]Thanks, Volker. I realize that files should be in the application bundle, and I wasn't suggesting to do it a different way. In the back of my mind, though, I'm wondering what that bundle looks like when copied to a PC. I'm hoping it's a directory.

    Do I correctly assume the path/to refers to the path to the source code? Or is that the target?[/quote]

    Thats the path of the source. The target path (relative to the bundle) is in the second line.

    If you just care about copying the Mac bundle to a windows box, then you're right, it is nothing more than an ordinary directory. On the Mac command line you just "cd" into it, like into every other directory. It's just the Finder that displays the bundle differently and if you call "open" on the command line, it does not open Finder (like for directories) but launches the application.

    Regarding deployment on Windows, that's a different beast. You'll probably consider using an installer to put everything in place. You find some hints on windows installers in "this thread":

  • Volker: you posted about the same time I edited my last post, so I'm not sure if you saw my new comments/questions?

  • The path is relative to the location of your .pro file.

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

  • 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

    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?

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


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

  • 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

    QT += declarative


    HEADERS +=
    SOURCES +=

    FORMS +=


    And here's a snapshot of my directory:



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

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


  • 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_PROPERTY( int combGainl READ combGainl WRITE setCombGainl NOTIFY combGainlChanged )

    void setCombGainl( int combGainl )
    // Only emit signal if new value is different
    if ( m_combGainl == combGainl )
    m_combGainl = combGainl;
    emit combGainlChanged( m_combGainl );

    int combGainl() const { return m_combGainl; }

    void combGainlChanged( int );

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

  • [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");

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

  • 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, that the next step?


    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?

  • 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

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

Log in to reply