[Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders

[Alan Alpert]

On Tue, Jul 2, 2013 at 1:26 AM, Thomas Hartmann
<Thomas.Hartmann at digia.com> wrote:
> Hi,
>
> the "problem" is that the ApplicationWindow/Window contains a
> contentItem and redirects the default property to this contentItem.
>
> This means Window looks and behaves like an Item when it comes to adding
> children and even anchoring. Therefore we have to treat it like an item
> for most cases like reparenting or anchoring, but not in all cases like
> states or deeper in the stack: painting.
>
> We have to live with the current solution anyway, but there would have
> been alternatives like:
>
> ApplicationWindowItem {
>      applicationWindow.menuBar: Menu {
>      }
>
>      applicationWindow.statusBar: StatusBar {
>      }
>
>     applicationWindow.toolBar: ToolBar {
>     }
> }
>
> In this case from the C++ side not too much would change, but the
> ContentItem would own the Window. There is still a one to one
> relationship from the ContentItem to the Window and there would be litte
> difference between ApplicationWindowItem and our current
> ApplicationWindow other then the fact that ApplicationWindowItem really
> is the contentItem not just redirects its default property.
> Note that ApplicationWindowItem would support states out of the box.
>
> If you look at it from a prototype based inheritance view it might get
> clearer. When using prototype based inheritance an x is an y if it
> behaves like an y (No static class hierarchies).
>
> In the ApplicationWindow case it behaves like an y in many cases,
> because of the default property redirected to an Item. Actually if
> treated as a fixed/static root item it behaves in all cases like an
> Item, except when it comes to states. Therefore I think it would have
> made sense to turn ApplicationWindow into a full blown y/Item
> (Than cannot be the child of another Item, though).


We could add a "states" convenience property with ease. Would that be
sufficient to make it a "y" in this explanation?

states/transitions have nothing actually to do with Item, we just
added those properties onto Item for convenience. So if it's common
enough that people want to define states/transitions on a window then
I see no issue with adding additional convenience. It's just a thin
wrapper around the StateGroup type anyways. We do want to provide
extreme convenience, like the default properties which Simon likes so
much :) .

ApplicationWindow is going to be a fixed root item in terms of how
it's used. Most users are going to use ApplicationWindow, not Window
(which is not always a fixed root item, but perhaps could be treated
as such in the design mode?), so that's the case we need to fix.

> This is the pure QML view. I do understand that from the C++ perspective
> Window is quite special, because it holds its own QtQuickView.
>
>  From the tooling perspective this means that we have to deal with
> ApplicationWindow/Window in many places since it behaves like a normal
> root Item and can be the target of anchors, while there is always a
> level of indirection to the contentItem.
>
> In the case that the contentItem would have been explicit:
>
> ApplicationWindow {
>      menuBar: Menu {
>      }
>
>      statusBar: StatusBar {
>      }
>
>     toolBar: ToolBar {
>     }
>
>     contentItem: Item {
>     }
> }
>
> we could at least "skip/ignore" the ApplicationWindow for all code that
> handles anchors, transformations etc, because we are only interested in
> the contentItem.

We have this same "half-hidden-content-item-redirection" in Flickable,
the only difference is that Flickable is actually an Item as well. How
do we solve this for anchors/transformations inside a Flickable onto
the "parent"?

--
Alan Alpert