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, <[email protected]> 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 > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt-qml regards, Jan-Arve _______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
