[Development] Window{} API for QML

[Alan Alpert]

On Fri, 11 Nov 2011 05:01:32 ext Adriano Rezende wrote:
> On Mon, Nov 7, 2011 at 5:32 AM, Alan Alpert <alan.alpert at nokia.com> wrote:
> > Given that there can be Desktop Components providing the full API for
> > desktop windows (and this is being discussed on the qt-components ML
> > already), I propose the following minimal Window{} API for QML core
> > (i.e. inside the QtDeclarative library)
> > 
> > Window {//Inherits QQuickItem
> >    property string title: "untitled"
> >    property bool fullscreen: true
> > 
> >    property int x
> >    property int y
> >    property int width
> >    property int height
> >    property bool visible
> > }
> > 
> > Now this item would end up being reparented into another QQuickCanvas on
> > another window after being created in the same engine as the main file.
> > This allows bindings to work between windows just fine. Because of the
> > reparenting though there are a few changes from QQuickItem which is why
> > I've duplicated x/y/width/height/visible. Arguably it shouldn't be a
> > QQuickItem because of this, but I think the easy access to anchors is
> > worth it.
> 
> 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).

>         width: parent.width
>         height: parent.height
>     }
> }
> 
> 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.

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks