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

[Alan Alpert]

On Fri, Jun 28, 2013 at 12:34 AM, Thomas Hartmann
<Thomas.Hartmann at digia.com> wrote:
> 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.

What QtQuick scene (currently inseperable from QQuickWindow) would
that QQuickItem be in?

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

There are loads of objects already which are not Items. Placing it in
a separate QtQuick.Window import is supposed to help remind people
that this isn't an Item derived type, so it doesn't have Item
functionality, same as QtObject.

If anything, this shows just how badly we've been documenting the
inheritance hierarchy for types. We need to at least make the
"Item"/"not Item" split clear for QtQuick.

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

I don't think it's that mature yet. The slowness of changes, both to
QtQml and QtQuick, I think are more because the shifting priorities
over the last year has moved a lot of effort away temporarily. When
Android, iOS, V4VM and QtQuick.Controls jumped in priority we had very
little in those areas, once we've got those under control I hope to
see the pace of QtQuick development 'quicken'.

I certainly have plenty of stuff I want to change (for QtQuick,
starting with the questions on that wiki page). Shame I can only do
one thing at a time...

--
Alan Alpert