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

[Alan Alpert]

On Thu, Jul 4, 2013 at 12:32 AM, Thomas Hartmann
<Thomas.Hartmann at digia.com> wrote:
> 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.

We've already started the "contentItem" pattern, and while one may
prefer the property to be private it's exposed because you do run into
issues in special cases where you need that access. So keeping to the
"contentItem" pattern sounds good for the future. I'll put that on the
wiki page.

Great feedback Thomas, thanks!

--
Alan Alpert