Adriano spaketh: > I'm moving a layout discussion to this mailing list. > > I've pushed an initial version of a linear layout element in the > following branch: <snip>,
First, +1, I agree with Bo that your work here is appreciated. QML absolutely needs to have some kind of "layout" capability and it's nice to see progress. Second, I have thought about this issue *a lot*, and it is not yet obvious to me what is "ideal" for QML. What follows is speculation and opinion. Sorry for the long email (below, which includes design thoughts). I just don't know where else to take discussions like this. ---------------------- ASSERTION: The QWidget (e.g., "desktop") model for real-estate usage (and "component ownership") is VERY DIFFERENT from the QML model. IMHO, great care must be taken in merging the models (we need to think this through). In the absence of "thinking it through", we'll merely super-impose the desktop model onto QML, which IMHO, probably won't work well. Maybe it will. I don't know. ---------------------- GOAL: We need to be able to specify "placement-and-real-estate-sub-division" for QML components. QWidgets do this with layouts, which is a "top-down" model. QML components currently are "independent actors" that do their own placement[*] (permitting Z-order). As a result, QML components can animate, move, and resize themselves. [*] The QML components can do some level of "anchoring-to-parent-component", but IMHO that is not a "fundamental" mechanism, because parent components are not required to themselves be "visible" (this is different for QWidgets). Further, things like QML "transitions" imply different size-and-placement concerns where "layout" capability may be needed between "parents" (such as transitioning components in a "flock-of-birds" pattern from one parent to another). ---------------------- ATTITUDE: I'm partial to a "typesetting" type convention, such as that from TeX/LaTeX, described by Knuth. It's very simple, and IMHO merges with the "layout"-type model well. (a) Each QML component has a "size", and a "horizontal-and-vertical-baseline-reference" point. (b) Items are physically placed based on their "baseline-reference-point". (c) "Layouts" may consider item "size" for its placing-and-spacing of items, but placing-and-spacing merely establishes a location for the items' "baseline-reference-point". (d) "Layouts" may attempt to impact a component's resolved "size", but is not the "final arbiter" (as it is in QWidget/QLayout). (e) The item can easily "shift" itself around its "baseline-reference-point". For example, this is a trivial way to perform animations within a component without forcing re-layout. (f) Conceivably, the "size" and "baseline-reference-point" could be 2D or 3D (or even n-D). ---------------------- DESIGNS OPTIONS: (A) "Top-Down" establishes a "manager" that establishes sizes for items, typically being the "final arbiter" for negotiated sizes after considering different opinions (e.g., what an individual widget/component wants, like "QWidget::sizeHint()", what space is available, what the sum of all the children want, margins-and-spacings, the "importance/weighting/stretching" of individual items relative to each other). (B) "Bottom-Up" means each component decides for itself how big it is, and where it should be placed. May consider "high-level" context, such as device-screen-size. This permits components to be "independent actors" that animate and move themselves. May cause problems as some components do not "play well" with others in establishing real-estate and usurping Z-order. Of course, IMHO, some level of "both" is required. Different applications have different needs, and fundamentally both designs "negotiate" a "final size" after considering some level of "sizing-and-placement" based on a context "greater-the-component-itself". (For example, the QWidget negotiates size based on QWidget::sizeHint()-and-constraints and the parent layout, while the QML component negotiates size based on parent component, anchors, and screen size.) IMHO, the key difference between these designs is that (A) uses a third-party "arbiter" for final real-estate decisions, while (B) does not. MY GUESS: QML probably needs a third-party "arbiter" for real-estate decisions (e.g., a "layout-type-thingie"), but IMHO it won't/shouldn't be the "final arbiter". For example, a "QML-layout-thingie" would establish "guidelines-and-context" and a QML component as an "independant actor" would make its final decision, subject to its internal constraints (like minimal size), parent constraints (like anchors-in-parents), and "unversal" constraints (like screen/device limitiations). Specifically, if there is support for my "typesetting" preference, the "QML-layout-thingie" would establish the placement for the QML component "baseline-reference-point", and the QML component *itself* could arbitrarily "resize" itself, and shift-itself-around its "baseline-reference-point". (That keeps the animations and dynamic nature of QML, and establishes alignment-and-placement-concerns among the components through the "QML-layout-thingie" like we conveniently have with QLayout on the desktop. ---------------------- DIFFERENCES TO KEEP IN MIND: In support of my assertion that "something-different-is-probably-required" for a "QML-layout-thingie", I merely want to highlight a few of the differences in the *existing* designs between QWidgets/QLayouts and QML-components that seem to be significant contrasts to me. (For the following, one could pretend "QWidget" is synonymous with "desktop".) (1) QWidgets uses layouts for (screen) real-estate subdivision. QML, at its core, does not. (2) QWidget is typically nested in parent QWidgets, while many QML components commonly are not. (3) QWidget is typically "statically presented" based on their parent QWidget being presented, while QML components are "independent actors" that decide when/how to present themselves (which is how QML components handle animation/transitions/movement). (4) QWidget clips its children, while QML components do not. (5) QWidget *implies* "visible" use of real-estate, while QML components do not (the parent QML component implies ownership, but NOT screen real estate). (6) A "visible" QWidget implies the parent QWidget is visible, while QML parent/child components do not (similar to (5)). (Another way to say this is that "visibility" and "real-estate" attributes are propagated along the parent/child hierarchy in QWidget, while it is not in QML components.) (7) QWidget "places" children (via QLayout), while QML components typically "anchor" their children left/right/top/bottom (or their children anchor themselves within their parent) (8) QWidget Z-order is implied through "ownership", while QML components have explicit Z-order (+n...) ...probably lots of other differences, the designs IMHO are quite different... ...hope I represented those properly (please feel free to correct me). ---------------------- NOTES: Great apologies to all for "hijacking" this thread, so I'll just throw in a summary of the "desires" that were explicitly mentioned in this thread, which a "QML-layout-thingie" might want to address: (a) Need to handle QML component stretching, individual item spacing, minimum/preferred/maximum size policies, like "row-layout" and "column-layout" (Adriano) (b) Want to center items vertically at their baseline by default (Jens,Adriano) (c) Need "splitters" (Jens) (d) (concern), The current "wrapping behavior" in QtQuick's "Grid" is different from GridLayout and cannot be unified (Jens) (e) Need to align QML components that are in different containers (like different group boxes) (André) (f) Want "typesetting" placement conventions for QML components (charley) ---------------------- In closing, it seems like we could really hit a great "sweet-spot" between (static) desktop layouts and (dynamic) independent-actor-components in a thought-out "QML-Component-Layout" design. I vote for a "typesetting" attitude with a "baseline-reference-point" for item placement to hit this balance. --charley
_______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
