QML and Qt Quick

My QtQuick initializing code: @MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) { ui->setupUi(this); QQuickView *view = new QQuickView(QUrl("qrc:/qml/main.qml")); QWidget::createWindowContainer(view, this); }@ I would guess that the problem is this line: @QWidget::createWindowContainer(view, this);@ Currently i am using a qtquick2controlsapplicationviewer and it works fine so far. Provisionally solved

You might also want to take a look at http://qt-project.org/wiki/Qt_for_Google_Native_Client

Hi, thanks for your suggestions. I agree that while(!WorkerThread->isRunning()); may be bad construct, but it doesn't solve the problem. Although GUI thread may freeze for awhile, it still continues and both threads are running. The run() executive is in different thread than gui, and the problem still persists. Ignoring "binding loop" message doesn't help either, when the gui thread still crashes - I guess only QQmlApplicationEngine has some poblem as outlined by this assert ASSERT: “engine->jsStackTop >= mark”

Thank you for the explanation. I like the new behavior of the GC, because it shows me that I have a problem in my code. So I can find it and fix it. Coming form only c++, I must say that the JavaScriptOwnership issue surprised me. For me it is odd, that someone else is deleting objects I created in c++. Thanks again.

I could not find any graphic-card settings on my mac so I could not test the upscale of the Mac display. For me it related with retina screen. Apps look way different even with the same res on both screen.

You can use either of them. QQuickItem uses the new Scene Graph type of rendering, while the QQuickPaintedItem uses the old QPainter. Performance of both are comparable.

I've solved the problem by putting some alias and regrouping the qml and image files into the same .qrc file but organized with different prefixes. But now I've got another problem. I've put all my qml files into the same qrc file and I'm trying to initiate a pathview with a ListModel. The List Model is in a file alone and the PathView in another qml file. I'm trying to do : @PathView { id: myPathView delegate: myDelegate model: myModel [...] }@ with my ListModel looking like this : @import QtQuick 2.0 ListModel { id: myModel ListElement { name: "MyElement1" } ListElement { name: "MyElement2" } ListElement { name: "MyElement3" } }@ But the pathview doesn't find the ListModel. When I tried something similar with a test projet and qml files that weren't in a .qrc file, it worked without any problem. It seems that when .qrc are involved, scopes are different... Any ideas ?

Hi onek24. I try the directional blur. It's great! In my case, moving a rounded rectangle, with no image inside. The effect is low. But great improvement. Gives a better movement sensation. Some details: 1- Because is a rounded rectangle. By default the blured area is defined by this rectangle, so I marked "transparentBorder = true". And play with the length of the blur. 2- I'm giving a direction, with each new position, to make the directionalBlur goes in the same way as the movement. Thanks for your help.

Ah, finally figured it out, TextInput has a property named clip that has to be set to true

You're welcome. Glad we could help you.

Hi, it's QtQuick.Controls 1.1, not QtQuick 1.1. Also, this page might be useful: http://qt-project.org/doc/qt-5/qml-qtquick-controls-textfield.html

This is a simple how to video that I followed and was able to get everything to work. It might help you, but without more information, I'm just taking a guess to what is wrong. "Tutorial":http://www.youtube.com/watch?v=_nkhlhBwkjk

ok, I will try controll from c++. Thank you for interest

Hmmm, You can use the StackView and re-use the same ListView over and over again if you want. When pushing a item onto the stack you can pass in arguments. See http://qt-project.org/doc/qt-5.1/qtquickcontrols/qml-qtquick-controls1-stackview.html section Pushing Items One argument could be the a reference to the model to be loaded. values in the properties argument the are applied on construction of the list view. Back is then automatically handled using pop() (selection preservation). The overhead in memory is to have all stacked list views in memory. If a list view is popped it will be destroyed. Also having these 20 different list view as separate files or components inside your project. If you need a C++ model, depends where your data comes from.