QML and Qt Quick

It's not a typo. I don't understand what conditions cause seg faults when I delete scene nodes. I'm pretty confused in general on how to deal with the new scene graph stuff since there's a separate render thread asynchronously doing stuff. If I have some custom opengl rendering in a QSGNode in the preprocess() call, will I get a seg fault when someone changes the QQuickView to another QML file and parts of my scene graph get deleted?

It will be a bad idea not to, especially now that symbian is pretty much a done deal, and Qt itself is portable enough to cover a wider range of much more lucrative mobile platforms.

Ah, didn't realise it was you, Kit :) Feel free to ping on #qt-qml if you have more questions. I'm sure a doc patch would be appreciated. The current docs as far as I know are "here":http://qt-project.org/doc/qt-5.0/qtqml/qtqml-syntax-objectattributes.html#attached-properties-and-attached-signal-handlers (for using attached properties/handlers in general) and "here":http://qt-project.org/doc/qt-5.0/qtqml/qtqml-cppintegration-definetypes.html#providing-attached-objects-for-data-annotations (for how to implement them in C++).

QStringList is a supported type. The subset of types known as "sequence types" have conversions to JS types - although the conversion is "imperfect" (as documented, it doesn't create properly sparse arrays, as C++ has no analogue). Sequence types include QStringList, QList<QString>, QList<QUrl>, QList<int>, QList<real>.

Thanks I didn't have a clue what a singleton was, but after lookign over that second link in the singleton example it makes a lot of sense, and I think that may be what I will ultimately need.

I don't find the correct way to change the QQuickView default framebuffer to an new explicit one.

I would not be surprised if the declarative view is blocking for the debugger to connect... with the debugger sitting there, considering his day's work done after the first view was closed:).

OK, I'll just go over in this corner and hide. How could I have been so stupid??!! Thanks! ;-)

Your amazing!!! Thank you, now I can move on with my project :D See I'm not even that familiar with C++, I don't even know what a singleton is :P Luckily the amount of C++ going into this will be minimal it's just to get variables from my C functions and pass them along to the QML, and vice versa. Is there a way to vote up replies? Or mark them as "Answers"? Like on other forums.

Thanks. I need to do that with QML and not C++.

Further research shows that this might be possible. Take a look at "this.":http://qt-project.org/doc/qt-5.0/qtquick/qmlmodule-qtquick-localstorage2-qtquick-localstorage-2.html

Can you post some code? How are you referencing the ListElement's parent? The QQuickListElement is an empty class that inherits QObject. It is filled dynamically using Qt's Property System. "qquicklistelement.h":http://qt.gitorious.org/qt/qtdeclarative/blobs/83e820ba767c2d37600d3536ebcfde18234d2f46/src/qml/qml/qquicklistmodel_p.h#line152

Take a look at the documentation: "Using QML Bindings in C++ Applications.":http://qt-project.org/doc/qt-4.8/qtbinding.html In particular, the section Exchanging Data between QML and C++ may be of interest to you. However, it is discouraged to modify a QML scene directly from C++, because it creates an unnecessary tight coupling between the UI and code-behind. Better way is to expose a QObject "model" to QML. Your QML scene state can then be controlled using the your model object's Q_PROPERTIEs. See the section Embedding C++ Objects into QML Components in the same doc article on how to expose objects from C++ to QML.

No. This signal is emitted when the scene graph has been invalidated. This signal implies that the opengl rendering context used has been invalidated and all user resources tied to that context should be released. The signal just informs you that the scene graph has been invalidated and that the OpenGL context has been released. Have a look at this "page.":http://doc-snapshot.qt-project.org/5.0/qtgui/qopenglcontext.html. If the context is temporarily not needed, such as when the application is not rendering, it can be useful to call destroy() to free resources. However, if you do so you will need to call create() again before the context can be used, and you might need to recreate any OpenGL resources and reinitialize the OpenGL state. You can connect to the aboutToBeDestroyed() signal to clean up any resources that have been allocated with different ownership from the QOpenGLContext itself. Have you confirmed that this is in fact your problem. Have you checked that this signal is being emitted? If not then my suggestions might not be so helpful.

Yes that is true. You can get a texture from a "QQuickItem":http://qt-project.org/doc/qt-5.0/qtquick/qquickitem.html only if it is a "textureProvider":http://qt-project.org/doc/qt-5.0/qtquick/qquickitem.html#textureProvider. At a quick glance, there doesn't seem to be anything that exposes an objects' pixmap.