On Fri, 11 Nov 2011 05:01:32 ext Adriano Rezende wrote: > On Mon, Nov 7, 2011 at 5:32 AM, Alan Alpert <alan.alp...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development