[Qt-qml] Advanced layout support

[jan-arve.saether at nokia.com]

I would like to mention some disadvantages to all approaches mentioned here: 
Unless we make some smart decisions, the suggestions will make layouting much more complex.
Such as:
* What if label.implicitWidth changes? This opens several sub-questions:
  -> How should propagation be done? (rearranging the layout as an answer to a change in every single size hint will cause many redundant rearrangements)
  -> What if the application have set a minimumWidth, should it just be overwritten (because of the property propagation)? This again opens the question how we can differentiate between min/max size (set by the user) and min/max size hints (indicated by the item). Should it be possible to override the size hints given by the item (just like QGraphicsLayoutItem allows?)

* How rigid is min and max sizes? Do they override the size property?

Jan-Arve

ext Adriano Rezende wrote on 2011-10-18:

> On Tue, Oct 18, 2011 at 6:20 AM,  <jens.bache-wiig at nokia.com> wrote:
>>> span, shouldn't be there since it's just used by the Grid. So,
>>> maybe a GridLayout would be better in this case, to avoid adding
>>> specific properties in the Layout attachment.
>> 
>> Yes, you are right about that. I think my proposal would only really
> with splitters and row/column layouts. So it might not be such a good
> idea after all.
> 
> We still need to provide min/max properties somehow. Consider the
> following (very common) use case:
> 
> // Button.qml
> Item {
>     minimumWidth: label.implicitWidth + margin // won't work but still
>     needed by layouts ....
> }
> 
> Follows the possible approaches to solve the above use case:
> 
> 1. Add min/max support in QtQuick
> 
> // Button.qml
> Item {
>     minimumWidth: label.implicitWidth + margin
>     ....
> }
> 
> * 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
> 
> 2. Provide a 'Widget' element in QtComponents
> 
> // Button.qml
> Widget {
>     minimumWidth: label.implicitWidth + margin
>     ...
> }
> 
> * 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.
> 
> 3. Provide a common attached property in QtComponents
> 
> // Button.qml
> Item {
>     SizeHint.minimumWidth: label.implicitWidth + margin // a better name
>     could be provided (Layout, SizeHint, ...) ...
> }
> 
> * Advantages - Don't need to add another component - Any element could
> be inserted in RowLayout, ColumnLayout and GridLayout
> 
> * Disadvantages
> - Not so explicit API
> 
> 4. Handle these information per layout
> 
> // Button.qml
> Item {
>     ...
> }
> 
> RowLayout {
>     Button { RowLayout.minimumWidth: 100; } }
> * Advantages - Each element can provide specific properties using the
> same attached property - Provide a more explicit API than the previous
> one (similar to ListView attached property)
> 
> * Disadvantages
> - Turn min/max implementation specific (layout specific)
> - It would be impossible to address min/max to any layout
> 
> 
> Personally, I prefer the first approach. But if an immediate API is
> necessary, I would go with the 3rd approach.
> 
> Still, some layout specific information are still needed, and we could
> handle that like the following:
> 
> RowLayout {
>     Item {
>         SizeHint.minimumWidth: 100
>         RowLayout.stretchFactor: 2.0 // just layout specific properties
>     }
>     Button {
>         RowLayout.spacing: 8 // just layout specific properties
>     }
> }
> 
> 
> Any feedback regarding these 4 approaches are welcome.
> 
> 
> Br,
> Adriano
> _______________________________________________
> Qt-qml mailing list
> Qt-qml at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-qml



regards,
Jan-Arve