Dmitry, you can read more on that in this wiki article: http://qt-project.org/wiki/QmlStyling Primarily, you are interested in section "Nesting QtObjects", but reading the whole article would be useful too.
In our application, we found it more convenient to do that in slightly different manner. We instantiate a single instance of that component (rather than making it be a true singleton) which is placed in the root .qml file and provided with some id (say, 'appStyle') which is supposed by our internal convention to be a global name used to refer from any other QML component. This trick allows us to live code UI components. True singletons lack this ability since they are not re-created at the time UI gets reloaded due to changes to .qml files. My collegue has noted that such implicit referring to an id out of component definition may impact QML engine performance. Maybe some one can elaborate more on this. Regards, Dmitry. On Fri, Dec 26, 2014 at 1:12 PM, Dmitry Q <linuxsquirrel....@gmail.com> wrote: > Hi. In the official QML documentation we see the following suggestion ( > http://doc.qt.io/qt-5/qtquick-performance.html): > > >>> > Use singleton types instead of pragma library scripts > > If you are using a pragma library script to store application-wide > instance data, consider using a QObject singleton type instead. This should > result in better performance, and will result in less JavaScript heap > memory being used. > <<< > > What does is mean? How should we use QObject singletons? For example, I > have the following ".pragma library" JS to store application-wide constants: > > .pragma library > var X = 10; > ... many other declarations... > > How should I rewrite this with QObject singletons? > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
