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

Alan Alpert 416365416c at gmail.com
Fri Jun 28 09:14:41 CEST 2013


On Thu, Jun 27, 2013 at 8:58 AM, Bubke Marco <Marco.Bubke at digia.com> wrote:
> Hi
>
> We have some implicit design decisions in Qml/Quick/FxItems but there is not
> really a documentation for it
> so changes are happen which are really hurting. Let give me a example:
>
> 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 ;)).

> So my proposal is to write all this informal decisions down in a wiki. If
> anybody wants to change that he should ask every stakeholder if it is ok
> etc..

*informal* and *implicit* decisions are by their nature hard to
reliably recognize and write down. I have no objection to writing up
QtQuick architecture in a wiki page that we can all contribute to and
discuss (here's a start:
http://qt-project.org/wiki/Qt_Quick_Architecture ), but we can't rely
on all the hidden details being there. Otherwise they wouldn't be
hidden.

As for asking every stakeholder, I fully agree that all changes to the
design should be discussed on the development ML. If that doesn't
reach every stakeholder, then maybe we need a new ML?

> Maybe something like the PEPs in Python.

I don't think that would work for an element set. Maybe for additions
to the QML language, but the QtQuick QML types are not a language
feature. They're also still in a rapid growth state, so I would prefer
a process no more cumbersome than an ML discussion (maybe update a
wiki page). PEPs looks a little heavy to me, at least for this stage
in the maturation of the module.

--
Alan Alpert



More information about the Development mailing list