[Qt-qml] Advanced layout support

[Charley Bay]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20111017/1688b201/attachment-0001.html