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

[Thomas Hartmann]

Hi,

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

I think this is a good idea. For the designer we could just work around 
it by creating a StateGroup, but I think adding a states and transitions 
property to ApplicationWindow makes the API more consistent.
We should ask for other opinions, though.

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

Yes. The concept of default properties is very powerful and adds a lot 
of convenience. But it is also tricky sometimes, because the parent in 
the text QML tree is not the parent in the actual SceneGraph/Item tree 
any more.

> 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 what we actually do. ApplicationWindow/Window can be the root 
item, but nothing else in the design mode.

> 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"?

We track these cases by running the parent chain until we find the 
"actual" Item (in this case Flickable). We also do take care of 
transformations.

There is one big issue, though. To avoid usability issues/flickering
we have to know the transformation beforehand. This means we have to 
know the transformation before we actually reparent the item.
The current solution is that we "advise" components to have a 
contentItem for these cases. Then we can check the transformation to the 
contentItem beforehand.
This is how it is done for GroupBox. If there is a transformation and no 
contentItem is defined items will "jump" when reparented.

In the near future I will collect these kind of requirements of 
components for the designer. Actually I only know of one other issue. 
Components often assume that some properties are fixed after component 
complete is called. While for applications this assumption is usually 
valid it breaks in the designer.

In a way both these problems were also relevant in the widget case and 
are not QML specific. The widget designer also has to know about "non 
standard ways" to add child widgets like addWidget() and widgets also 
have to gracefully handle use cases which are only relevant for the 
designer.
QWidget was lacking component complete though and the imperative C++ API 
implies that also normal users set properties in an unexpected order and 
such.
While I think component complete is necessary (I even requested it back 
when I started to try QML), I would prefer if in the future it is used 
for real special cases and for all the standard cases we would rely on 
signal compression in the engine.

About the default property alias to a contentItem, I would like to see a 
standard pattern, so we do not haven to tool dozens of exceptions.
Hinting the content item by exposing it as either "contentItem" or 
"__contentItem" is a good start.

Kind Regards,
Thomas Hartmann