QML and Qt Quick

Thanks for your reply and the hint with the proxy model. A good working solution was now implemented using the following design: One AbstractListModel holding all the data A SortFilterProxyModel to filter the data based on the page number is instanciated for each page, using the Repeater + Loader inside of the SwipeModel The source component of the Loader holds a ListView that is using the ProxyModel as a model

Have you prepared your models through balsam? https://doc-snapshots.qt.io/qt6-dev/qtquick3d-tool-balsam.html

@JonB No, it is dynamic linked.

As far as i know, the controls defined in the style need to inherit from Template classes (e.g. T.Dialog {...}).

I was also seeing the same strange error and struggling to work out where it came from: qmldir file not found at "some/path" turned out it was a call to qt_import_qml_plugins. Not sure what this means in the context of this conan build, though.

@Mizmas said in In QML, how to stop children from inheriting parent properties like opacity?: @jeremy_k Thanks it worked, I wish the Item type had a property to wrap around it's children though, I've tried using childrenRect.width with childrenRect.height for the parent Item's size, but it was a bit messy, at least in the Qt Design Studio. I'm not sure that I understand the issue. Are you saying that you want a single property to make the parent the same size as the children, rather than 2? I don't use design studio, but I don't see the a mess running the same code via creator. Another option is to make the background the child of the piece, with a negative z.

@RokeJulianLockhart Have you read through https://www.ics.com/blog/whole-shebang-running-qml-files-directly ? Apparently it works? But I have to say, since QML files use // not # for comment line, I don't see why or how or where it is documented....

@LeoJeams can you try to replace Window with ApplicationWindow? import QtQuick.Window for Window and import QtQuick.Controls for ApplicationWindow

@peter-thompson said in What is the best practice for passing C++ data objects to QML that is contained in a QQuickWidget?: @jeremy_k said in What is the best practice for passing C++ data objects to QML that is contained in a QQuickWidget?: I had not noticed a warning against setting properties in root objects. That's the method I prefer, as it resembles what I would generally do if instantiating the component as a node of a larger QML tree. Properties of the root component can serve as documentation of inputs. Multiple property initialization functions such as QQmlComponent::setInitialProperties() might be more efficient. The warning I was referring to is mentioned in two places: Overview - QML and C++ Integration and Interacting with QML Objects from C++. It says: Warning: Although it is possible to access QML objects from C++ and manipulate them, it is not the recommended approach, except for testing and prototyping purposes. One of the strengths of QML and C++ integration is the ability to implement UIs in QML separate from the C++ logic and dataset backend, and this fails if the C++ side starts manipulating QML directly. Such an approach also makes changing the QML UI difficult without affecting its C++ counterpart. I think it may be specifically referring to navigating the QML object tree and setting properties/invoking methods on child objects. So it might not apply to working with the root object alone. That's my reading, and hence the subsequent surprise. I generally attempt to treat children of widget instances similarly. If there are a significant number of QQuickWidgets, consider instantiating an independent QQmlEngine, rather than relying on each widget to create its own. This is an interesting idea that I had not considered. How would this work? Would I still use QQuickWidgets to integrate the QML with the widgets visually/structurally, and just pass the already-created QQmlEngine instance that they should use? Exactly. The engine comes with a component cache, network access manager, and some additional configurable features that can be more efficient to reuse.