QML and Qt Quick

Try running your application with the QML_IMPORT_TRACE set to 1 and look at the messages in the console.

That's normal. You had two applications fighting for the same resources (your application and the X server).

They should refer to the Qt AlignmentFlag enum. Therefore, you should be able to do something like this: Q_PROPERTY(int hAlign READ getHorizontalAlignment NOTIFY objectChanged) Q_PROPERTY(int vAlign READ getVerticalAlignment NOTIFY objectChanged) int MyClass::getHorizontalAlignment() { return Qt::AlignHCenter; } int MyClass::getVerticalAlignment() { return Qt::AlignBottom; } TextEdit { anchors.fill: parent text: "Hello World" horizontalAlignment: MyContextPropertyOrModel.hAlign verticalAlignment: MyContextPropertyOrModel.vAlign }

I got it, thanks

Ok I think i have got it. The following did the trick. I added anchors.fill in Sandbox.qml root item. I removed the code for view3d render mode setting from the main.qml into the sandbox.qml file so the Component.onCompleted just does this Component.onCompleted: { dynamicallyCreatedItem = Qt.createComponent('qrc:/Sandbox.qml').createObject(window, {value1: 0.5, value2:0.5, value3:0.5, value4:0.5, value5:0.5, value6:0.5, isEnabled1: false, isEnabled2: false, isEnabled3: false}) toptitle.text = dynamicallyCreatedItem.sessionText } Doing this works fine and I get the two viewports as in original code. The issue is solved. The github repo contains the correct code for anyone who is stuck.

It turns out that zoomReset() resets the scroll as well, so all the scrolling made while zommed in is reverted: (from the Docs) Note: This will also reset scrolling and explicit axis range settings specified between the first zoom operation and calling this method. If no zoom operation has been performed, this method does nothing.

Loving the attitudes here.......waiting for someone else to provide a fix, yet not one of you have bothered posting a code snippet for 'us' to look at or play with. Help us help you, the more info you give, the better the help is likely to be and if dragthreshold doesn't work, why are only 5 people complaining about it?, I suggest your code is mising something.

Sorry for disturbing. This is the answer: https://doc.qt.io/qt-5/qml-qtquick-listview.html#cacheBuffer-prop

@Mantas-Kast It's kind of an old topic, but I am curious. Have you found a satisfactory answer to your topic by now? Imo, FLUX/FELGO are the best practices for qml architecture. There should be a global "store" and global "actions". It allows you to change your UI quickly without any pain. Calling qml from c++ should be done via Connection where target is your C++ object and your UI "action" is called. Calling C++ from qml should be done via C++ object, defined in setProperty in qmlEngine.

You have to tweak the layout behavior to match your requirements. Per default, all available space will be distributed equally between all children. import QtQuick.Window 2.15 import QtQuick 2.15 import QtQuick.Controls 2.15 import QtQuick.Layouts 1.12 Window { width: 500 height: 400 visible: true ColumnLayout { // set outer bounderies for layout, not in the children anchors.fill: parent anchors.rightMargin: parent.width / 2 spacing: 10 anchors.margins: 10 Label { Layout.fillWidth: true // disable taking more height then required Layout.fillHeight: false color: "darkgray" text: qsTr("Type your text below") wrapMode: "Wrap" font.pointSize: 14 } ScrollView { Layout.fillWidth: true // automatically fill empty height // > if you would set this to TRUE for multiple children, the available // space will be equally distributed between them Layout.fillHeight: true TextArea { // you don't need width&height or anchors.fill here // TextArea automatically fills ScrollView background: Rectangle { color: "red" } // use Wrap instead of WordWrap to avoid long single // words to overflow // > Wrap automatically prefers WordWrap wrapMode: "Wrap" padding: 10 } } } }

Hello again! I stumbled into this behavior again, as one of my files, where I used relative paths, has changed its Qt.resolvedUrl behavior "overnight". I was not yet able to find out which commit has broken it, as the the built binaries do no behave the same all times, weird... :O The file lies under @/Base/Interface/+foo/ and Qt.resolvedUrl("../") does now resolve to qrc:/Interface/+foo/ and not qrc:/ as like before. The need for using relative paths came as the absolute paths with "qrc:/" were not working as expected under all circumstances (see previous post). So I decided to give that a closer look again. Here is what I found out so far: All that cases I had shown in the first part of the previous post, do work correctly when I encapsulate the source's string into a Qt.resolvedUrl. That means, I no longer get a completely different result for Image { source: "qrc:/Assets" + "/logo.png" when I do that by saying: Image { source: Qt.resolvedUrl("qrc:/Assets" + "/logo.png") With that the image's source gets resolved correctly to qrc:/Assets/+foo/+bar/logo.png The same counts for StateChangeScript { script: imageSource = Qt.resolvedUrl("qrc:/Assets/error.png") } where 'imageSource' is still a property of type string, but the image's source gets resolved correctly to qrc:/Assets/+foo/+bar/error.png. And also for PropertyChanges { target: image source: Qt.resolvedUrl("qrc:/Assets/error.png") } the source gets resolved correctly to qrc:/Assets/+foo/error.png Does anyone have a clue on what Qt.resolvedUrl does in an other way than the implicit conversion of strings to urls? Naively you will think like, this will happen internally by using Qt.resolvedUrl, but yeah... Regards, matzze.