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

[Alan Alpert]

On Fri, Jun 28, 2013 at 2:52 AM, Rutledge Shawn
<Shawn.Rutledge at digia.com> wrote:
>
> 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.

The items-in-a-scene is an implementation detail (albeit one of the
biggest ones), but if you can provide a better implementation for the
existing APIs then that would be ideal. If not, we need to start
considering trade-offs instead, and maybe these other use-cases are
not as important as the application running with high performance
on-device. The initial usecases were not MDI, and were not even
multi-window. We aren't going to throw in extra abstraction layers for
a "potential future". It's much better to maintain flexibility to be
able to add abstractions later on, even though abstractions are
easiest to implement at the start. One of the hopes for the QML-only
API of QtQuick is that we are only restricted by QML versioning
(separate from Qt versioning), and this gives us more flexibility.

Maybe for QtQuick 3.0 we can apply an extra abstraction to fix this,
or even a minor version of 2.x depending on how it's implemented. So
long as we don't have the complete scene breakage (like between
QtQuick 1 and QtQuick 2) or critical performance loss, there's scope
to add this in later.

--
Alan Alpert