I have a Loader object in my main QML file. I load different QML sources in the loader at run time depending on the current context.
My steps are like this:
Load a login.qml file and set anchors.centerIn: parent on the Loader.
After successfully logging in, I load task.qml and then set anchors.fill: parent on the Loader.
After the user logs out, I want to redirect back to login.qml, and I set anchors.centerIn: parent again on the loader.
I would expect this would cause the Loader to be centered in the parent and no longer fill it. However, this is not the case. The Loader still fills the parent.
How do I change the anchors on an Item so it is centered again and no longer fills its parent?
You don't need to set anchors.centerIn again. Instead, you need to set anchors.fill and width and height to undefined so it defaults to the implicit size and again uses the anchors.centerIn property.
Here's a working example:
import QtQuick 2.0
import QtQuick.Controls 1.0
Item {
width: 800
height: 600
Rectangle {
id: rect
anchors.centerIn: parent
implicitWidth: 500
implicitHeight: 200
color: "red"
Button {
text: "Toggle Full Size"
anchors.centerIn: parent
onClicked: {
if (rect.anchors.fill) {
rect.anchors.fill = undefined
rect.width = undefined
rect.height = undefined
} else {
rect.anchors.fill = rect.parent
}
}
}
}
}
Alternatively, a simpler solution might be to make your Loader always fill its parent and instead add an extra Item at the top level of your login.qml file so the login view is centered in this Item. That would remove the necessity to change the anchor on the Loader.
Related
The following QML code:
Window {
id: window
width: 450
height: 700
visible: true
StackView {
id: mainStack
property Item itemTest: Item {
id: itemTest
ColumnLayout {
id: mainLayout
width: mainStack.width
ScrollView {
id: scrollview
Layout.fillWidth: true
Layout.fillHeight: true
clip: true
ScrollBar.horizontal.policy: ScrollBar.AlwaysOff
ColumnLayout{
id: colLayout
anchors.fill: scrollview
}
}
}
}
initialItem: itemTest
anchors.fill: parent
}
}
outputs "QML ColumnLayout: Cannot anchor to an item that isn't a parent or sibling."
Replacing "anchors.fill: scrollview" by "anchors.fill: parent" in the above code makes this message disappear but then the ColumnLayout does not seem to fill the ScrollView.
Given this behaviour, I come to the conclusion that the ScrollView in this QML file isn't actually the parent of "colLayout", which comes against my first intuition about the way parenting works in QML.Can someone explain to me what is meant exactly by the keyword "parent" in QML ? Many thanks in advance.
The issue is that Controls use the concept of a contentItem. While the ScrollView itself is a Control which itself is in turn an Item, the children are parented to a different Item called contentItem.
More info here:
https://doc.qt.io/qt-5/qml-qtquick-controls2-control.html#contentItem-prop
See also the comment there:
Note: Most controls use the implicit size of the content item to calculate the implicit size of the control itself. If you replace the content item with a custom one, you should also consider providing a sensible implicit size for it (unless it is an item like Text which has its own implicit size).
You don't want to grow your ColumnLayout to match the contentItem, the contentItem will automatically resize to fit the implicit size of the ColumnLayout.
If the effect you are trying to get is to match the size of the ColumnLayout to that of the ScrollView, then use something like:
ColumnLayout{
id: colLayout
implicitWidth: scrollview.width
implicitHeight: scrollview.height
height: implicitHeight
width: implicitWidth
}
But in that case, why bother using a ScrollView? Normally you would allow the ColumnLayout to manage its implicit size normally based on it's children. When the contentItem ends up overflowing the ScrollView, then it starts to automatically scroll.
I work on a Qt project, where almost all of the QML Items are in the same file main.qml.
The application uses StackLayout to navigate through other QML files, plus the need to present the Items within the main.qml itself.
I use Loader to call a Component containing a GridLayout containing Labels and Images. Outside this container, there are other Images and Labels anchored to the bottom of the mainWindow.
Problem is, when calling the Component within the StackLayout using Loader, the Component dimensions cover the Image defined in the ApplicationWindow. It behaves as fillHeight all the Window which is not what I desire.
Question is, how can I load the Component without it filling the whole Window, but keeping the same size it originally was before using the StackLayout.
I'm still a beginner at Qt, so any other preferred methods of suggestions are welcome.
The code structure is similar to this,
ApplicationWindow {
id: mainWindow
width: 500
height: 400
(... some code ...)
Image{
anchors.bottom: parent.bottom
anchors.left: parent.left
anchors.bottomMargin: 22
anchors.leftMargin: 24
width: 80
height: 40
fillMode: Image.Stretch
source: "qrc:/image.png"
}
StackLayout {
id: mainStackLayout
width: mainWindow.width
height: mainWindow.height
FirstPage {} // another .qml file
Loader {
sourceComponent: component
}
}
Component{
id: component
GridLayout {
id: grid
width: mainWindow.width
height: mainWindow.height
columns: 4
Labels{}
...
...
...
Labels{}
}
The issue is primarily that you have setup your StackLayout to cover the entire window with:
width: mainWindow.width
height: mainWindow.height
and StackLayout will grow its children to fit its size.
Two simple options:
Place your Loader inside of an Item so that the Item grows instead and your loaded component's size is not affected.
Put a layout on the ApplicationWindow so that your Image and your StackLayout are managed better in relation to each other.
I'd recommend option 2. Unless you aren't going to allow users to resize your window, all of your QML components should be designed to be resizable.
This examples gives me property binding errors:
file:///home/user/qmltests/layouts.qml:22:4: QML Label: Binding loop detected for property "font.pixelSize"
file:///home/user/qmltests/layouts.qml:22:4: QML Label: Binding loop detected for property "font.pixelSize"
file:///home/user/qmltests/layouts.qml:18:4: QML Label: Binding loop detected for property "font.pixelSize"
Code:
import QtQuick 2.11
import QtQuick.Controls 2.4
import QtQuick.Layouts 1.11
Page {
id: root
width: 400
height: 200
StackLayout {
id: main_container
Layout.fillWidth:true
Layout.fillHeight:true
ColumnLayout {
id: sub_container
Layout.fillWidth:true
Layout.fillHeight:true
Label {
text: "One"
font.pixelSize: sub_container.height*0.2
}
Label {
text: "Two"
font.pixelSize: sub_container.height*0.2
}
}
}
}
By logic, this shouldn't happen, because I am copying the width and height down to lower level components by using Layout.fillWidth=true and layout.fillHeight=true
To fix this error, I have to copy the heigth from the root element:
import QtQuick 2.11
import QtQuick.Controls 2.4
import QtQuick.Layouts 1.11
Page {
id: root
width: 400
height: 200
StackLayout {
id: main_container
Layout.fillWidth:true
Layout.fillHeight:true
ColumnLayout {
id: sub_container
Layout.fillWidth:true
Layout.fillHeight:true
Label {
text: "One"
font.pixelSize: root.height*0.2
}
Label {
text: "Two"
font.pixelSize: root.height*0.2
}
}
}
}
Why aren't width and height propagated from the root elements down to children layouts?
How can I reference sub_container.width and sub_container.height (because it is known before items are laid out) without getting binding loop error? I don't want to reference the root item because due to complexity there may be many layouts inside root item and in order to lay out components in a scalable way I need to know the width and height of the parent layout.
If you use layouts, the elements they manage must not change their size based
on size given by the layout. To do what you wish to do, you shouldn’t be using a layout, but anchors, since you want to manage the child sizes manually. The loop is there because the layout uses the size of your item to resize itself, that your item then uses to resize itself, endlessly. If you don’t need that functionality, it will interfere – as you have seen. The reason it worked via root is that root’s size is not managed by the layout: it’s fixed. And that’s what you wanted all along, isn’t it?
Another approach would be for the label not to change its size hint based on font size, so that the layout wouldn’t react to the font size change.
TL;DR: Layouts size themselves based on child sizes, thus there’s a loop if the child sizes itself based on the layout’s size.
I tried to play with cacheBuffer, but it's only help me to increase count of cached delegates, when I want to disable caching at all.
Now with zero caching buffer my example (only one item stretched on all ListView) behaves like this:
At the start ListView creates two delegates: currently visible and
next one.
When I scrolling list forward it creates and keep up to 4 delegates without beginning destroying them.
When I start scrolling list backward it begin immediately destroying delegates without looking on cacheBuffer.
If you replace "height: root.height" to "height: listView.height", it will create delegates for all model items at the start.
Is this behaviour normal? Can I change it some way?
You can tried it yourself:
import QtQuick 2.11
import QtQuick.Controls 2.4
import QtQuick.Window 2.11
import Qt.labs.calendar 1.0
Window {
id: root
visible: true
width: 640
height: 480
title: qsTr("Hello World")
ListView {
id: listView
anchors.fill: parent
snapMode: ListView.SnapOneItem
cacheBuffer: 0
model: 10
delegate: Rectangle {
width: parent.width
height: root.height
// height: listView.height
border.color: "black"
Text {
anchors.centerIn: parent
text: modelData
}
Component.onCompleted: {
console.log("Delegate completed")
}
Component.onDestruction: {
console.log("Delegate destruction")
}
}
}
}
Replace
delegate: MyVeryComplexDelegate {
}
by
delegate: Loader {
width: expectedDelegateWidth
height: expectedDelegateHeight // Otherwise you might create all...
sourceComponent: MyVeryComplexDelegate {
}
active: someCriteriaYouFeelGoodAbout()
}
Now you will only have simple Loaders in your cache and you can decide which ones of those in the cache are active.
Probably better: Have parts of the MyVeryComplexDelegate loaded as the ListView wants, and just hide the most complex parts behind a Loader that turns active only if you really need the full complexity.
On your strange findings as far as I can explain them:
Regarding the difference between root.height and listView.height, the explanation is an issue that is subject to many questions:
While root.height references the property height of the window, which you have explicitly set, listView.height is determined by anchors.fill: parent, which results in setting the height to root.contentItem.height - and that is initially 0. Therefore the delegates, initially all have a height of 0, all of them would fit in the view and therefor have to be created, even if you load as lazy as possible. Later they will resize together with the root.contentItem and some will be destroyed again.
You can see that, when monitoring the height changes of your delegates and your ListView
The next thing is, that even if the delegate really fills the ListView from the beginning, a second delegate is instantiated. The reason for that is, the condition used by the ListView, when to create new delegates. For that the sum of heights - the displacement of the first has to be larger than the ListView. That is not fulfilled when it is equal to the height.
Increase the height of your delegate by a fraction of a pixel, and you are good.
height: root.height + 0.0001
Qt/QML question. Using Qt 5.7.
Take the following simple QML program that displays a red rectangle and a blue rectangle aligned vertically. Click handlers for both rectangles attempt to change the color of the parent host window. But with a subtle difference. The red rectangle references the host window directly by it's id (rootWindow). The blue click handler changes color via a parent reference.
The former case works fine. The latter case does not work. It seems like the root window is treated specially and isn't directly part of the parent/child hierarchy, even if the Rectangles are logically nested in the code that way.
Can someone explain the rule around this?
import QtQuick 2.7
import QtQuick.Window 2.2
Window {
visible: true
width: 640
height: 480
title: qsTr("Hello World")
id: rootWindow
color: "#ffffee"
Rectangle {
id: rect1; width: 50; height: 50; color:"red"
MouseArea {
anchors.fill: parent;
onClicked: {
print("rect1 clicked");
rootWindow.color = "green"; // works fine
}
}
}
Rectangle {
id: rect2; width: 50; height: 50; color:"blue"
anchors.top: rect1.bottom
MouseArea {
anchors.fill: parent;
onClicked: {
print("rect2 clicked");
rect2.parent.color = "pink"; // does not work
}
}
}
}
If you add the following line to the onClicked handler, you'll see that its parent isn't the Window:
print(rect2.parent)
Output:
qml: QQuickRootItem(0x18b18147bc0)
This is explained not-so-visibly in the documentation for Window:
If you assign an Item to the data list, it becomes a child of the Window's contentItem, so that it appears inside the window. The item's parent will be the window's contentItem, which is the root of the Item ownership tree within that Window.
The window itself isn't an item, so it uses contentItem instead so that child items can have a parent.
However, in Qt 5.7, Window got an attached property that can be used to access the window of an item:
rect2.Window.window.color = "pink";
Whichever item comes before the Window.window part will be the item that the attached property is used on. You could use it on any item in this scene (e.g. the MouseArea), as they all belong to the same window.
Note that attached properties create a QObject-derived object for each unique item they're used on, so be mindful of how you use them, especially in items that are created in very large numbers.