QML and Qt Quick

What worries me is the fact the echo() slot is never triggered. Not even as the application is closed. This leads me to believe such objects returned to QML are practically leaking, and I am not a big fan of believing somehow this is not the case. I don't like memory leaks. And somehow QML seems to be full of those. I've already encountered situations where QML doesn't release resources and memory usage climbs to hundreds of MB and never drops down.

Hi, I can not reproduce your issue. Could you elaborate little bit more. It would be perfect if you could show the exact code that shows the problem. @ Item { x: 200 y: 200 width: 200 height: 200 scale: 2 Rectangle { border.color: "black" border.width: 2 anchors.fill: parent } Rectangle { id: item1 x: 10 width: 5 height: 100 color: "red" Rectangle { x: /*item1.x +*/ item1.width width: 5 color: "green" height: 100 } } } @ This didn't show any gaps. Do you have rotations on your items and/or are they Images?

I marked the tread as SOLVED, as the problem is now understand. Would still be interesting to know if this behavior s intended or not, might be the Mailing List will answer this.

Unfortunately creating a sample application won't be possible because the application is quite complex. For now I am using a sleep() just before showing the application.

Problem is finaly solved!

[quote author="chriadam" date="1332833133"]QML already does this. A QObject which is returned to QML from an invokable function as a return value has its ownership semantics set to JavaScriptOwnership if it has not previously been explicitly set to CppOwnership. [/quote] How does this work considering QObject can't be returned by value?

To summarize: The compiler adds the option of letting you compile QML and javascript into efficient C++ code, giving you the option of more effectively hiding/obfuscating your QML in commercial applications and improving the initial startup time of QML applications as it takes away the compilation step at runtime. It does not affect what is currently available in the open source edition.

Since our application always runs full-screen, the only time it gets hidden is when it gets closed - so I subclassed QQuickView with my own MainView and wrote my own override hideEvent() that did the necessary shutdown.

Hi, It should rather be: @engine.rootContext()->setContextProperty("TheCalc", &calc);@ Hope it helps

I just read "this post":http://www.qtcentre.org/archive/index.php/t-41193.html?s=4f0051811b94e81a668de909e4c9df15, which suggested that to get the blocking semantics you should implement a QDialog with blocking semantics, having your QML as the contents of the QDialog. That might give the blocking semantics, but I don't think it would give you the benefit of a native dialog look-and-feel that QML Dialog ought to give you.

[quote author="onek24" date="1417697726"]Hey benlau, I would say the same, i'll look into it if i find some time today. Keep us up to date if you found out something new :)[/quote] well , It is better to let Qt developer to declare an official document about the order. Otherwise, what we did is just a dirty hack .. In fact, I have encountered the problem of initalization sequence for several times already.

yes, it is. parent is object type which is have the "width"' property, but the parent himself is wasn't created

You're Welcome. Have fun :)

Hi, If I'm not mistaken you can pass the engine object to the class and then find the root object there. @ //main.qml Window { visible: true width: 640 height: 480 title: qsTr("Hello World") } //main.cpp QQmlApplicationEngine engine; engine.load(QUrl(QStringLiteral("qrc:///main.qml"))); QObject *rootObject= engine.rootObjects().first(); //rootObject will point to Window @ In your case you can either pass rootObject to your class or pass engine to the class so that you can find root element there.

Hi, What exact error are you getting ?

Good...so tag thread's title with [SOLVED]