What is the difference between width/height
and implicitWidth/Height
in QML? When should one set the implicit dimensions instead of the regular? When should one ask the implicit dimensions instead of the regular from a component/item?

- 2,583
- 3
- 35
- 59
-
6Great question! I've been struggling with this for quite a bit too! – Georg Schölly Aug 29 '17 at 19:22
-
6Excellent! Lot's of people struggle with this, when starting with QML. – derM - not here for BOT dreams Aug 29 '17 at 22:59
3 Answers
Generally, usage of implicitHeight/Width
only makes sense within reusable components.
It gives a hint, of the natural size of the Item without enforcing this size.
Let's take a Image
as an example. The natural size of the image would map one pixel from the image file to one pixel on the screen. But it allows us to stretch it, so the size is not enforced and can be overridden.
Let's say now, we want to have a gallery with pictures of unknown dimension, and we don't want to grow but only shrink them if necessary. So we need to store the natural size of the image. That is, where the implicit height comes into play.
Image {
width: Math.max(150, implicitWidth)
height: Math.max(150, implicitHeight)
}
In custom components, you have a choice on how to define the sizes.
The one choice is, to have all dimensions relative to the components root
-node, maybe like this:
Item {
id: root
Rectangle {
width: root.width * 0.2
height: root.height * 0.2
color: 'red'
}
Rectangle {
x: 0.2 * root.width
y: 0.2 * root.height
width: root.width * 0.8
height: root.height * 0.8
color: 'green'
}
}
In this case, there is no natural size of the object. Everything works out perfectly for each size you set for the component.
On the other hand, you might have an object, that has a natural size - that happens, e.g. if you have absolute values in it
Item {
id: root
property alias model: repeater.model
Repeater {
id: repeater
delegate: Rectangle {
width: 100
height: 100
x: 102 * index
y: 102 * index
}
}
}
In this example you should provide the user with information about the natural size, where the content does not protude the item. The user might still decide to set a smaller size and deal with the protrusion, e.g. by clipping it, but he needs the information about the natural size to make his decision.
In many cases, childrenRect.height/width
is a good measure for the implcitHeight/Width
, but there are examples, where this is not a good idea. - e.g. when the content of the item has x: -500
.
A real life example is the Flickable
that is specifically designed to contain larger objects than its own size. Having the size of the Flickable
to be equal to the content would not be natural.
Also be careful, when using scale
in custom components, as the childrenRect will not know about the scaling.
Item {
id: root
implicitWidth: child.width * child.scale
implicitHeight: child.height * child.scale
Rectangle {
id: child
width: 100
height: 100
scale: 3
color: 'red'
}
}
And to your comment: I just don't understand why it is better to set implicitWidth/Height instead of setting width/height of a component's root dimension.
implicitWidht/Height
are not a necessety - QtQuick could do without them. They exist for convenience and shall be convention.
Rule of Thumb
When you want to set dimension of a root node of a reusable component, set
implicitWidth/Height
.
In some cases, set it for non-root-nodes, if the nodes are exposed as a property.
Do so only, if you have a reason for it (many official components come without any).
When you use a component, setwidth/height
.

- 13,081
- 4
- 49
- 89
-
Thank you derM and Georg Schölly for your answers. I like this answer slightly more, because it has a bit more in depth explanation and +1 for the "Rule of Thumb". Also thanks for the answer for my comment. I was thinking something similar, that it is a good practice. Accepting this answer for now, but I hope there will be other posts/comments/discussions about this. – Silex Aug 30 '17 at 09:08
-
Very nice complete answer. The tag was lacking a good answer on this topic. :) – BaCaRoZzo Sep 02 '17 at 09:57
-
2One important thing is missing in my opinion : the role of implicit size when you use the item in a layout, which is close to QWidgets/QLayout behaviour with sizeHint. – ymoreau Mar 28 '18 at 08:54
-
@ymoreau: I have not worked with the QtQuick.Layouts much, yet. I will investigate it and update the answer if necessary. Thanks for pointing me to this. – derM - not here for BOT dreams Mar 28 '18 at 16:01
-
@derM Any updates when it comes to `Layout` types? Reading this doc it it seems that using `implicitX` over `x` makes sense in layouts as well: https://doc.qt.io/qt-5/qtquicklayouts-overview.html#specifying-preferred-size – pooya13 Sep 14 '20 at 05:44
I don't have the definitive answer but I can tell you what I found out. First, from the documentation:
implicitWidth : real
Defines the natural width or height of the Item if no width or height is specified.
The default implicit size for most items is 0x0, however some items have an inherent implicit size which cannot be overridden, for example,
Image
andText
.
but less informative for width:
width
Defines the item's position and size.
The width
and height
reflect the actual size of the item in the scene. The implicit size is some kind of inherent property of the item itself.1
I use them as follows: When I create a new item and it can be resized, I set an implicit size inside the object2. When I'm using the object, I often set the real size explicitly from the outside.
The implicit size of an object can be overridden by setting height and width.
an example: TextWithBackground.qml
Item {
implicitWidth: text.implicitWidth
implicitHeight: text.implicitHeight
// the rectangle will expand to the real size of the item
Rectangle { anchors.fill: parent; color: "yellow" }
Text { id: text; text: "Lorem ipsum dolor..." }
}
an example: MyWindow.qml
Item {
width: 400
height: 300
TextWithBackground {
// half of the scene, but never smaller than its implicitWidth
width: Math.max(parent.width / 2, implicitWidth)
// the height of the element is equal to implicitHeight
// because height is not explicitly set
}
}
1) For some elements, like Text, the implicit height depends on the (not-implicit) width.
2) The implicit size usually depends on the implicit size of its children.

- 124,188
- 49
- 220
- 267
-
10In short: implicit size is the space the object would like to occupy, size is the space it does actually occupy. – Felix Aug 29 '17 at 20:05
-
4Note that for `Text`, `implicitWidth` is the width the text would occupy if there's no wrapping. `contentWidth` is the actual width of the `Item` if there is wrapping (it's equal to `implicitWidth` if there is no wrapping). – GrecKo Aug 29 '17 at 21:03
-
1I think this is how I understood it as well. So in a nutshell use implicit dimension for "presetting" the dimensions of a component and use regular dimensions when you want to "overwrite" that. Implicit dimension is kind of like a fall back value if regular width/height isn't set. Am I making sense here? – Silex Aug 29 '17 at 21:47
-
@Silex: Yes, and also implicit width / height can be used when setting the explicit width / height. – Georg Schölly Aug 29 '17 at 22:02
-
4From my experience, I came to the conclusion that you should use implicit size if you want to refer to a child size, and explicit size if you want to refer to a parent size. When creating a new component, don't hardcode the size, use implicit sizes instead. I tried to illustrate it in an example but momentarily gave up since it's hard finding a meaningful one :) – GrecKo Aug 29 '17 at 22:02
-
2I just don't understand why it is better to set `implicitWidth/Height` instead of setting `width/height` of a component's root dimension. Setting the regular width/height would work the same way as fall back if I don't specify one where ever I create the given component. – Silex Aug 29 '17 at 22:34
-
I like your logic about children, parent and corresponding dimension usage @GrecKo though! – Silex Aug 29 '17 at 22:37
-
1@Silex For example lets say you are the component user, you wouldn't be able to do `size: size * 2` (let's say for some reason you want to stretch the element twice its default size) But you can do `size: implicitSize * 2` – pooya13 Sep 15 '20 at 00:12
Implicit size is supposed to be used when calculating size of an item based on its contents. Whereas setting width
or height
on a parent item may affect the size of its children it should never be a case, when you set implicit size.
Rule of thumb
Implicit size should only "bubble up", i.e. children should never lookup for implicit size of their parent to calculate their own implicit size, neither parent should try to force implicit size of its children.
If you would try to set width
on a component similar to layout, that initially calculates its width from the width
(rather than implicitWidth
) of its child item and that child is affected by the size of a parent, you would end up with a binding loop.
This is why the property exists - to break cyclic dependencies when calculating size of an item based on its contents.

- 8,355
- 6
- 53
- 72
-
What if you want to create a resizable RowLayout that fills it's parent? Shouldn't you explicitly set the parents size and then have the elements of the layout be sized with respect to their parent (the layout)? – pooya13 Sep 14 '20 at 05:57
-
@pooya13 yes, you can set the size of the parent explicitly. Then the parent may set the size of its child explicitly. The question is how `RowLayout` should behave, if you don't set its size. If you won't set the size of the `RowLayout` neither use its attached properties`RowLayout` will use implicit size of children to calculate its own size. – mip Sep 14 '20 at 10:05