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

[Thomas Hartmann]

Hi,

>> Every graphical item should be derived from QQuickItem. So for graphical
>> content in a Qml file there should be a item as root object. But now there
>> is ApplicationWindow which looks a little bit like a bastard. It is actually
>> a QuickView aka a Window with the special property contentItem. So we break
>> a design decisions which is really hurting the qml designer. Thomas  has
>> written some magic code after he has seen the wizard of Oz with his daughter
>> but you know he hasn't still not seen all this Harry Potter movies so it is
>> working somewhat but not very well. To get it working very well we had to
>> rewrite our adaption code around the existing C++ interface of Qml. And how
>> Alan stated it, it is not a clean interface. It would take much time and
>> would generate new bugs. You see this is generating work. Work which would
>> be not existing if we would had sticked to the design decision that every
>> graphical item is a quick item.
>
> Every item in the graphical scene still is a QQuickItem. A
> QQuickWindow encapsulates a new graphical scene, and I don't quite
> have the magic to contain a new scene inside itself.
>
> I don't think we want to go down the QWidget route of having every top
> level item implicitly create a window. It worked for widgets because
> it fit naturally into their static and boxy implementation. In
> QtQuick, where you throw Items and Rectangles around like candy just
> to build the same functionality as a single widget (still less LoC,
> but a lot more QObjects...), I can't see that working very well (until
> someone builds it and proves me wrong ;)).

I was not paying enough attention when QQuickWindow was introduced. So 
am not innocent in this case. But I still think composition would have 
been the better choice.

While I agree that a QQuickItem should never become a toplevel window in 
an implicit manner, we could have done a QQuickTopLevelItem that 
contains a QWindow but still is a QQuickItem.

I think this would have made some things easier for QtQuick, for users 
and for tooling. For example a QQuickWindow has no states and 
transitions. This is just confusing and inconsistent.

But now we have QQuickWindow and it is public API. So we have to live 
with it.

But since QML/QtQuick is getting more mature I have to agree with Marco 
that introducing something like PES or RFCs to specify the language, 
item set and the general design more closely would help. This will of 
course not happen overnight and it will add some bureaucratic overhead, 
but changes to the language (QML) and to the core item set are not that 
common anymore and have a lot of impact for all stake holders.

Kind Regards,
Thomas Hartmann