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

Rutledge Shawn Shawn.Rutledge at digia.com
Fri Jun 28 11:52:38 CEST 2013

On 28 Jun 2013, at 9:14 AM, Alan Alpert wrote:

> On Thu, Jun 27, 2013 at 8:58 AM, Bubke Marco <Marco.Bubke at digia.com> wrote:
>> 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 know, but that's really too bad because it would make many things possible:
- anchors only work with items, so if windows and screens were items we could use anchors with them more easily
- on platforms which don't support multiple top-level windows (Android, RasPi etc.), we need to pretend that they do anyway, and synthesize the window decorations by putting the window contents into wrapper items. The dialogs module solves this its own way by creating a QML dialog inside of an Item, instead of putting it in a window.  https://codereview.qt-project.org/#change,59474  But that's just a one-off solution, which will need to be repeated later on in other contexts such as
- MDI windows and dockable windows
- compositing window managers (but that's been done, even in Qt; goes to show the "magic" is really possible)
- and of course the tooling, designers, debuggers and anything else that introspects and manipulates objects at runtime

In old versions of Visio, a group, a stencil and an embedded drawing appeared to the user to be more or less the same thing.  You could open up a group and modify its contents without ungrouping it first; and you could easily create your own stencils, and instances of those also behaved like instances of an embedded master drawing.  Every drawing/diagramming/CAD tool should have this feature (but even Visio got broken later on).  In the same way, a rectangular area should be an interface which has implementations such as: 1) a plain rectangle just for storing coordinates without implying anything else 2) scene-graph item 3) event-receiving area (like MouseArea etc.) 4) window 5) screen 6) desktop.  It's crippling that nobody seems to have thought of abstracting it at the beginning.  But it's easier to think that the application can only have one window from which there is no escape, and that therefore it's outside the scope of QtQuick.  It just doesn't work for the long term; and then as soon as you add windows you run into the lack of homogeneity in the windowing system too, where a window is too heavyweight (and the operations to manipulate it are cross-process messages) so you can't afford to create a window for each item.  But at least the abstract window could have created either a real window or an item transparently; and after all the trouble with implementing dock windows the first time, the need for abstraction should have been obvious to anyone with some experience.

More information about the Development mailing list