[Qt-qml] Advanced layout support

[Charley Bay]

charley spaketh:

> <snip, desktop "layout" design should be different from QML "layout"
> design, me desire "typesetting-type-interface" for QML>


Jens respondeth:

> I am afraid I still don't quite understand how you are proposing that
> layouts should change. What we are currently discussing is simply extending
> and adding convenience to the mechanisms (Row, Column) that are already
> present in the language. As a developer, I suspect that presenting some
> small code snippets that demonstrate what this will look like is a more
> effective way of communicating your ideas. Keep in mind that baseline
> anchoring, is already fully supported in Qt Quick. We simply need to set the
> text baseline on the components themselves to enable this feature.
>

If the goal is incremental-extension-to-what-is-already-there-in-QML, I
agree.  If the goal is for QML-layout-migration-to-be-more-like-desktop,
then I similarly agree.

In this respect, I don't have any specific code requests for doing anything
differently (current progress looks fine to me).

However, IMHO, making QML-layouts work like QWidget-layouts won't work
long-term.  It seems like that's what we're doing.  It seems fraught with
corner cases that haven't been considered.  I could be wrong.

Fundamentally:  QML components are "independent actors" for
sizing-and-placement-and-animation, or they are not.  The QWidget/desktop
model says they "are not", and thus, they are/can-be subject to a layout.
 It remains unclear to me how QML components can be both, if the concept of
a QML-layout is the same as the concept of a QWidget-layout.

I would advocate a different design.  For a different design, I concede (1)
It's not a small amount of code; (2) The way one thinks about layouts in QML
is different; (3) The "approach" and "theory-of-behavior" would require
non-trivial explanation (so a "small code snippet" would probably be
insufficient).

I assume this means it is outside-scope for now (Qt5).  However, since we
are trying to *understand* the new metaphor that is QML (not QWidget), IMHO
we should be "honest" about the issues regarding "layout".

For a code snippet, though, an example of a "typesetting interface" for "QML
layouts" would be something like the following:

MyComponent {
  // As per a "proposed" QML "component standard", all "visible" components
always have:
  //   size2dcore - "core" size to be used for layout
  //   size2dreal - "real" size approximating what is drawn (may be
more-or-less)
  //   baseptcore - baseline-reference-point that is "set" by
parent-or-layout
  //   baseptshift - baseline-reference-point that is "shiftable" (typically
for animations/transitions)
  states: [
    State {
      name:  "big";
      PropertyChanges {
        size2dreal.width: size2dcore.width * 2.0;
        size2dreal.height: size2dcore.height * 2.0;
        baseptshift.x: -width/2.0;
        baseptshift.y: -height/2.0;
      }
    },
    State {
      name:  "normal";
      PropertyChanges {
        size2dreal.width: size2dcore.width;
        size2dreal.height: size2dcore.height;
        baseptshift.x: 0;
        baseptshift.y: 0;
      }
    }
  ]
}

MyLayout {
  // RECALL: Layout for all components is computed by considering:
  //   my_component.size2dcore
  //   my_component "size-hints-and-constraints"
  //
  // RECALL: Layout can ONLY set the following values on a component:
  //   my_component.size2dcore  (real-estate "allocated" to component)
  //   my_component.baseptcore  (absolute placed reference point)
  //
  // ... upon a new component added to our layout, set all component
  // "size2dcore" and "baseptcore" values...
}

Some notes on this type of design (PROPOSED, NOT REAL FOR TODAY):

(a) As per a revised QML standard, all components would have "well-known"
size-and-base-point attributes, some of which are set "externally" (by the
parent, or by the layout), and some of which are set "internally" (such from
"internal animations/states/transitions").  The "final resolved" is a
combination of the "external" and "internal" attributes.

(b) The parent component *need not* have a "layout".  Either a parent
component *or* an external layout could set the "external" attributes.
 (Layouts establish regular patterns, and some parent components are mere
logical containers with no visual context.)

(c) The component typically "controls" its internal attributes.  This
enables animations/transitions without perturbing the parent layout.  Since
both "internal" and "external" attributes are combined for final
placement-on-the-device, the component can compliment, amplify, accept, or
suppress external constraints.

(d) A component may be BOTH a "child" of a parent component, *and* a member
of a "layout" which is independent of that component's parent component.

This example is the kind of "theory-of-operation" that I want to see
discussed.  While the above design *could* manifest in a final
syntax/convention like today's QML "parent-anchors" and the previously
discussed RowLayout/ColumnLayout (indeed, the above design would permit
those to be trivially implemented), I'd guess that more elegant syntaxes are
possible within the QML application-specific components.

> (e) Need to align QML components that are in different containers (like
> different group boxes) (André)
>
> I don't think that is something we can or should solve in Layouts. The
> question seems to be if you could anchor to something that is not the
> immediate parent.
>

I agree with André, I want this too.  In QML, it is inconceivable to me that
we don't enable this type of capability.  My design above would permit this
(in fact, the design is partly inspired by this need/goal).

It is concerns like these that prompt me to suggest that the current effort
to "make-layouts-in-QML-look-like-desktop-layouts" will likely, ultimately,
be unsuccessful.  I could be wrong.

> (f) Want "typesetting" placement conventions for QML components (charley)
>
> Again, we might need some code to get a better understanding of what you
> are proposing.
>

I could make further code examples after a clear
typesetting-theory-of-operation statement. The theory-of-operation statement
itself would be a new approach (not like desktop layouts), and thus would
probably require a "book-chapter" length discussion.

However, I hope the code examples above are sufficient to describe how such
a design approach would be different?

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20111018/9149bf0b/attachment-0001.html