A few design questions...

mzimmers

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.

andre

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

ZapB

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;
view->setSource(QUrl::fromLocalFile("myqmlfile.qml"));
view->show();
@

mzimmers

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.

ZapB

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

mzimmers

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

does using QML mean that I'm no longer using my widget.ui file, or do they work together?
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.

Thanks!

andre

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

mzimmers

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.

ZapB

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.

mzimmers

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":http://developer.qt.nokia.com/forums/viewthread/656

Which seems related, but not quite the answer.

Any advice on how to handle this?

ZapB

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

mzimmers

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.

giesbert

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

mzimmers

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?

giesbert

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?

mzimmers

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?

giesbert

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

mzimmers

But...it'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?

giesbert

but the *.pro files are described in the qmake "documentation":http://doc.qt.nokia.com/latest/qmake-manual.html

"lmgtfy":http://www.lmgtfy.com/?q=qmake+adding+copy

e.g. "this page":http://paulf.free.fr/undocumented_qmake.html

or this on "stackoverflow":http://stackoverflow.com/questions/3984104/qmake-how-to-copy-a-file-to-the-output

ZapB

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.