[Development] Window{} API for QML

Adriano Rezende adriano.rezende at openbossa.org
Fri Nov 11 17:16:39 CET 2011


On Fri, Nov 11, 2011 at 2:45 AM, Alan Alpert <alan.alpert at nokia.com> wrote:
> On Fri, 11 Nov 2011 05:01:32 ext Adriano Rezende wrote:
> > I think the Window element should not inherit from QQuickItem, since
>> it's not an element in the render tree; it's basically a window
>> representation that is not affected by parent transformations or
>> effective opacity. The anchors feature is not a big advantage if it
>> brings to an API bloat; one could also achieve the same results
>> creating a wrapper like the following:
>>
>> Item {
>>     anchors.fill: parent
>>
>>     Window {
>>         x: // map to global
>>         y: // map to global
>
> What do you mean here by 'map to global'? If x/y are global coordinates, then
> the anchors won't work because the x/y are set by anchors assuming relative
> coordinates. But relative coordinates make no sense if it's not affected by
> parent transformations (although you have a point that it probably shouldn't
> be).

Well, I'm ignoring parent transformations (rotation, translation, ...)
since it would be a strange behavior to apply rotation to a
sub-window, just because it's 'embedded' in a rotated item. As I see
the Window should not be dictated by local scene transformations.

The anchors would affect just the wrapper's coordinates. If Window
position must be defined as global coordinates we should map (item.x,
item.y) to global. The problem is that this kind of binding would have
a high cost, since we would need to track position changes in all
parent hierarchy in order to keep the global coordinates updated, so
it would be better to set these properties just before opening the
window.

The problem I see with the QQuickItem inheritance is that it brings a
lot of features that would have null effect on a Window unless they
are properly addressed (which is a hard task). Consider the following
use case:

Window {
    rotation: 30 // will we support window rotation?
    clip: false // what this would mean ?
    anchors.fill: parent // It would be really binded to a different
scene coordinate? The user would loose control over x,y Window
position?
}

>> Internally the Window element could create a (or maybe inherit from)
>> QQuickCanvas or QQuickView and move its children to a root contentItem
>> like the Flickable API.
>>
>> This would provide a more symmetric (and QML oriented) API, since we
>> could do something like:
>>
>> // main.qml
>> Window { // top level window
>>      Item {
>>          Window { // sub window
>>
>>          }
>>     }
>> }
>
> I can see how it's a bit more symmetric, but doesn't it mean that every Window
> must have exactly one child item, which will almost always be an Item{}?
>
> One thing I liked about having Window{} be a QQuickItem was that it had the
> one root Item{} built in for convenience. Then you can have multiple children
> and anchor to parent and other stuff that requires an Item{} (which you just
> manually create if it isn't built in). This invisible Item{} though is what
> places it in the render tree.

Yes, the Window would have internally a root Item that will be the
real parent of its children. But the user wouldn't need to create this
Item explicitly, it could work like the Flickable API. So, the
following declaration would work:

Window {
    Rectangle { id: rect1; anchors.fill: parent }
    Rectangle { id: rect2; anchors.fill: parent }
}

Internally these two items would be parented to Window.contentItem,
but in order to work, the parent should be set before evaluating the
bindings (the anchors in this case).


Br,
Adriano



More information about the Development mailing list