[Qt-qml] Advanced layout support

[Adriano Rezende]

On Tue, Oct 18, 2011 at 2:08 PM, Charley Bay <charleyb123 at gmail.com> wrote:
> 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.

The goal is to provide extended layout features, not to replace the
way QML handle item layouts.

> 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.

Both layout approaches can live together, like Row, Column and Grid
components live together with the QML anchoring system. The difference
is that extended size policies would be introduced.

> 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...
> }

Your emails are a little verbose for me :). I'm a lazy reader.

What you are proposing couldn't be handled with translate
transformations or item wrappers?

Like:

Item {
    Item {
        x: 10
        y: -20
    }
}

Br,
Adriano