[Qt-qml] Advanced layout support

Adriano Rezende adriano.rezende at openbossa.org
Wed Oct 19 16:29:47 CEST 2011


On Wed, Oct 19, 2011 at 5:11 AM,  <jens.bache-wiig at nokia.com> wrote:
>> 1. Add min/max support in QtQuick
>>
>> * Advantages:
>> - Clear and explicit API
>> - Native support without 3rd party extensions
>> - We could add min/max support for the QML anchoring system (like
>> QGraphicsAnchorLayout)
>>
>> * Disadvantages:
>> - I can't see any
>
> I don't neccessarily disagree, as having it built into the language seems like the obvious solution. But I don't think it is _that_ clear cut:
> - If we do not support those constraints it for anchors, but give items properties like minimum/maximumWidth, it would just add to the confusion.
> - Adding constraints could have a significant performance penalty for low end hardware. Hopefully this would be negligible if you don't make use of them.
> - Giving anchors hard constraints can impact how easy it is to animate certain things. Making layouts explicit makes it easier to determine when you are giving away control over positioning.
> - Giving anchors constraints makes them unpredictable. Who wins when you have conflicting min/max sizes? The largest item? Most likely by random? Again, I somewhat like the distinction that anchors are somewhat more rigid/harder and wins over layouts every time.

Yes, size constraints do not play well with anchors. Basically it's
hard to find a good way to solve conflicts; enough to say that
QGraphicsAnchorLayout uses Simplex to handle them :). I agree, that it
would not be a good choice regarding performance and smooth
animations.
Maybe that would be used just for Row and Column if extra features
were added, but probably it's something that may not be high priority
for QtQuick2.

>> 2. Provide a 'Widget' element in QtComponents
>> * Advantages
>> - Clear and explicit API
>>
>> * Disadvantages
>> - Add an intermediary element just to handle min/max, increasing the
>> hierarchy tree.
>> - Just widgets could be added to RowLayout, ColumnLayout and
>> GridLayout, diverging from Row, Column and Grid idea.
>
> I personally do not this idea because you make it much harder to mix and match regular QML with components.
> Would putting an item between two widgets remove their constraints?

I think if custom layout management will stay at qt-components domain
it would not be a so bad idea after all.
A best effort could be made to handle Item and Widgets, but just
Widgets will provide all information needed (a fixed size policy could
be used by default for non-widget items), and also an Item could be
wrapped in a Widget, like LayoutItem approach, in order to have a
better integration.

A Widget could have:

Widget {
    minimumWidth
    minimumHeight
    maximumWidth
    maximumHeight
    verticalSizePolicy
    horizontalSizePolicy
}

The rest of layout specific properties would be provided by each
layout, like RowLayout.stretchFactor.

I'm just not discarding this option, but I don't know if having Widget
as a base class for all qt-components items would worth it.

>> Personally, I prefer the first approach. But if an immediate API is
>> necessary, I would go with the 3rd approach.
>
> I agree. I think the hybrid solution would be a good compromise. i.e that you have a Layout/SizeHint attached property in addition to RowLayout.

Yes, maybe the following arrangement could be an initial proposal. If
a better one is suggested we can go with it.

Layout.minimumWidth
Layout.minimumHeight
Layout.maximumWidth
Layout.maximumHeight
Layout.verticalSizePolicy
Layout.horizontalSizePolicy

RowLayout.spacing
RowLayout.stretchFactor

ColumnLayout.spacing
ColumnLayout.stretchFactor

GridLayout.span
GridLayout.row
GridLayout.column
GridLayout.rowSpan
GridLayout.columnSpan

Do you think Splitter could use the Layout attached property?

> But I just noticed (and excuse me if it is well known) But there are actually two existing complete layout examples for GridLayout and LinearLayout that ships with Qt 4.7 already.
>
> They both seem to favor the LayoutItem approach:
>
> http://doc.qt.nokia.com/4.7-snapshot/declarative-cppextensions-qgraphicslayouts-qgraphicsgridlayout-qgraphicsgridlayout-qml.html
> http://doc.qt.nokia.com/4.7-snapshot/declarative-cppextensions-qgraphicslayouts-qgraphicslinearlayout-qgraphicslinearlayout-qml.html

I remember these components. They just expose QGraphicsLayout API to
QML. Maybe that was the reason why they chose a LayoutItem wrapper.

I don't like this approach because it's different from anything QML
provides. The dependency of an alien wrapper makes the API more
confusing, one would easily try to add an Item directly in the layout.
Also, other parts of the API seems wrong, like setting minimumSize as
string (minimumSize: "200x300").


Br,
Adriano


More information about the Qt-qml mailing list