QML and Qt Quick

I find the solution of above problem. problem is related to continous intterupt received by CPU from SD card io driver which leads to poor perfromance of whole system.

I have re-checked the case with a clear project and came to the idea that my observations were dependent on what I do when properties of an object are being set. That last time I had a sistem which automatically sets up a GUI element onWindowChanged (for that object) event if it is possible (new window is fine). So what really depends on simple/well syntax is which properties of parent object are set first. I suppose with simple-syntax the default property is resolved and set first of all, when using well-syntax results in properties resolved in order they appear in QML description. @// 1: Image { window: system.graphic ButtonSilver { x: 20; y: 170; } } // 2: Image { window: system.graphic content: [ ButtonSilver { x: 20; y: 170; } ] }@ With option "1" I've got "content" property for Image resolved and set first, and then "window" was set, resulting in gui-Image backend instantiated later then it was done for a button backend. Hence option "2" provides more kind of expected order, which however shouldn't matter as QML is declarative language. It is up to me to make my plugin as declarative as QML expects.

Thank you, Chris, this seems more like it is in Qt sources: custom append function implemented for property. I think such an implementation really gives you more control over the situation, will give it a try. However, @{ connect(t, SIGNAL(somePropertyChangeSignal()), obj, SLOT(doWhatever())); ... emit obj->mylistpropertyChanged(); }@ I'd use metacall for that, if connect is to be made each call like here. May be you wanted to say connect is somewhere else around. But I got the point, thanks.

Out of interest, why do you use two QQuickViews to implement this use-case? Can't you use a single engine to manage the object hierarchy? Cheers, Chris.

Actually, the keyword "this" has specific meaning defined in binding expressions, however is undefined in signal handlers and other dynamic functions. See http://qt-project.org/doc/qt-5.0/qtqml/qtqml-javascript-hostenvironment.html for more information.

Yes.. Great.. Thanks for help. :)

This is good news, I just read your post in the mailing lists, after double-checking that it is not an April's fool I'd say I am glad there is work being done in this direction and will be waiting for some examples.

What I've found is that currently the easiest way to know whenever the GridView's currently selected index has changed is to create a helper class that has a Qt metasystem registered property: @ Q_PROPERTY( int selectedIndex READ selectedIndex WRITE setSelectedIndex NOTIFY selectedIndexChanged ) @ Then make your helper class accessible by QML: @ qmlRegisterType< ItemSelectionModelQmlHelper >( "Models.Tools", 1, 0, "ItemSelectionModelQmlHelper" ); @ Then create an instantiate of this class and expose it to QML: @ QDeclarativeView* const view = new QDeclarativeView; ItemSelectionModelQmlHelper* const helper = new ItemSelectionModelQmlHelper( this ); view->rootContex()->setContextProperty( "_itemSelectionModelQmlHelper", helper ); @ Then one can create the QItemSelectionModel and listen to the helper's signal, so that to set the current index of the QItemSelectionModel. Of course as mentioned above, if you use a sorting or filtration of the data being displayed in the GridView the currently selected GridView item's index may not correspond to a row in your QAbstractItemModel derived class. This won't be the case if you have done the filtration and/or sorting in C++ using the QSortFilterProxyModel. The problem with the non-coresponding index will arise only if you do the sorting/filtration in QML. It would be best if GridView has the option to specify a selection model.

Oops sure. ^^' Now, it's just : @C:\Dvl[...]\src\main.cpp:34: erreur : no matching function for call to 'QObject::connect(ImageManager*&, const char*, QQuickItem*&, const char*)'@ Was just a stupid problem of import...

Hm, thank you very much, I'll now go and derive from QDeclarativeParserStatus. I didn't want QDeclarativeItem because I don't need all of those built-in utils for visualization, but this status-class is exactly what I need. bq. QDeclarativeParserStatus provides a mechanism for classes instantiated by a QDeclarativeEngine to receive notification at key points in their creation. This class is often used for optimization purposes, as it allows you to defer an expensive operation until after all the properties have been set on an object.

refresh

Anyone can further provide update on this ?

OK, thanks for the replies. I make large applications, I will not do something great with QML, but will not be small. will have many of user interface screens, maybe 30 ~ 50. do not want heavy application. Will it consume too much CPU or Memory or will it take to start?

I don't know much about why this warning is emitted, but it happens when the (in this case, default) GLSL shader (and in this case, I assume it's a fragment shader) is compiled. We're getting well out of my area of competence, but I think that there's probably an issue with ANGLE regarding how the GLSL shader is converted to HLSL, which causes an assignment (most likely of a uniform) to a different type, causing an implicit truncation. Build your Qt with desktop openGL configuration instead of ANGLE, and you should see this go away. Cheers, Chris.

http://stackoverflow.com/questions/9153629/regex-code-for-removing-fwd-re-etc-from-email-subject Found something for the above

I have been trying to use the Qml-grid view in my code. I am on a mission to couple it with my C++ code which I have been in vain so far. I think my problem occurs when I try to generate the signal from the qml rectangle. I will definitely update you with the results once I have done with it. "super-beta-prostate.com":http://www.super-beta-prostate.com

I'm not entirely sure what you mean, so maybe my advice won't be useful. But, basically: your "QML module" will be installed to a directory (the QML import path). Your application, which imports that module, can reside wherever it likes, it just needs the correct import statement. For example, if in your application's QML file you have: @ import com.example.components 1.0 @ then the QML engine will look in $QTDIR/qml/com/example/components for the module specification file ("qmldir"). You shouldn't need to include any of the paths to anything, in the .pro/.pri files of the application itself. To answer your final question, yes it's absolutely possible to define plugins with C++ defined types - there is a section about that in the documentation. Your plugin cpp should use qmlRegisterType (and related functions) to register the C++-defined types as QML types. Cheers, Chris.

waitForFinished blocks the event loop so converterStarted and converterFinished will be called one after the other after converterProc has ended thus you won't see "Wait!". If you just want to avoid several start of the converter and keep you UI responsive, you could disable pushButton while the converter is running.